ざっくりいうと多分こんな感じ↓
メインクエリーとサブクエリーの関係
query_postsとwp_query、get_posts
pre_get_posts
まとめると、
サブクエリー系：(3).wp_query (4).get_posts
以下、解説。
1. query_posts()
一旦セットされたメインクエリーを書換えるのでパフォーマンスが悪い。
wp公式では非推奨。
ページャーの使用は問題ない。
2. pre_get_post
ページを読み込む前の段階で、メインクエリー自体を希望のものに作成する。
他の方法に比べてパフォーマンスが良い。
ページャーの使用も問題ない。
現時点では多くのサイトがこの方法を推奨している。
3. wp_query
メインクエリーと同じ型のクエリーを、もう一つ別に作る感じ。
中身は投稿に関するものだけでなく、ページに関する情報など広範囲。
ページャーの使用には難あり。ただし解決方法は簡単。（後述）
4. get_posts
wp_queryと比較すると、wp_query ＞＞＞＞ get_posts
基本的に投稿の情報のみを取得する。
wp_queryとの比較で複雑なことは出来ないが、例えばサイドバーに「最新イベント情報」などとして特定の投稿タイプ10件のみを表示といった場合には、むしろwp_queryより動作が速くなるであろう点ではアドバンテージがあると思われる。
ページャーの使用は検索すれば出てくるけど、ややこしそうなのでパス。
各クエリーとヘージャーの関係
ページャーが参照するのは常にメインクエリー。
たとえサブクエリー内にページャーを設置しても、ページャーはメインクエリーを参照してページリストを作成する。そのため総ページ数や表示投稿数の相違などの不都合が生じる。
解決するためには、下記のようにオリジナルのクエリーをページャーに渡してやればOK（wp_pagenaviプラグイン使用時の記述）
wp_pagenavi(array('query' => $custom_query));
記述箇所はループの終った所。独自wp_queryのpost_dataをリセットする直前。
ここで再度整理。
- query_posts（メインクエリーを作成）
- pre_get_posts（メインクエリーを作成）
- wp_query（サブクエリーを作成、ページ情報も取得）
- get_posts（サブクエリーを作成、ページ情報は取得しない）
つまり、実質的にこの対応が必要となるのは、wp_queryでサブクエリーを作成した時のみとなる（はず）。
また、テンプレートページ内でクエリーを作成する場合は、下記の記載を加えるないと表示する投稿が送られない。
$paged = (int) get_query_var('paged');
$args = array(
'paged' => $paged,
…クエリー続き
);
つまり、query_postsとwp_queryでサブクエリーを作成し、ページャーを使用する場合はこの対応も必要となる。