meta_keyを複数の条件で変数に代入しindexに表示

普通に考えたらこうではないですか？
$meta_key = array( 'hoge-date','hoge-date02','hoge-date03','hoge-date04' );

仕様としましては、現在２週間分表示されていらっしゃいますデータをメタで設定してある４つの要素のうちいずれかが合致していれば表示し、合致がなければ表示しないということでしょうか。
データベースとしては平行して複数の条件を単一の項目にあてがうのは直接的なクエリでないとむつかしいと思います。
間接的に処理しようとする場合は、表示されている２週間分のデータについてget_post_meta(get_the_id(), "hoge-date", true);などで抽出して検証しそれを表示ないしは変数に格納してしかるべき処置にするというのはいかがでしょうか。

ご仕様について理解しました。
各個人の月業務ないしは個人を示す記事があり、それに日程の許容が４つメタでついている状態でしょうか。
２週先までの範囲をその４つあるメタを見て、存在すれば取り上げるということで範囲内の予定のある各記事ないしは個人を引き出す、と考えました。

この場合問題がいくつかあるのではと、以下に注意していただければと思いました。
・記事の日付を毎回書き換えるのでしょうか。
　履歴となった場合、指定範囲内を検索する母数がまいかい「全記事数」になりたいへんだと思います。母数を絞る方法が必要ではないでしょうか。
　履歴がいらない、という場合は記事を毎回変更する形でよいと思いますが、そうなるとその元記事、履歴の残る情報が電子または物理でお持ちではないでしょうか。
　もしその元となる情報があるならば、その掲載規則をそのまま取り込むのがよいのではないかと思います。

・メタに４つ項目が必要でしょうか。
　日程の許容として４段階あり、それをわけるものだと思いますが、個別に役割はあるのでしょうか。たとえば１の日程と２の日程の意味するところは違いますでしょうか。
　早出は１、時差は２などあった場合、それらを単体で抽出するタイミング（母数が全体になるのを避ける）があるならば必要かと思いますが、どれも同じ当番で候補の件数上限が４であるならば、メタはひとつで改行などのセパレータを使用して複数日書き込んではいかがでしょうか。
　日付が範囲にふくまれているかどうか、を検索するには多少ほねがおれますが機能性は向上すると思います。
　日付の目的が均一であればタグでもよいのではと思います。履歴を残されるのであればタグの量がふえてしまいますが月ごとなどで個人記事を書き換えるのであえば日付だけ３１個のタグがあれば足りるのではないでしょうか。
　また役割と日の関連性が高くあるならば、それらの関係性を記事か関連性のみを記載したメタにして、抽出する日付となるものは別途用意をするのはいかがでしょうか。

これらをふまえて、まずメタテーブルから日付の範囲内を検索して、それに結びつく母体の記事を列挙するのがよいと思うのですが、記事に結びつけ肥大化した表示用の記事を抽出するのはあまり効率がよくない気がします。
データベースを直接操作すればたやすいと思いますが準備関数で、となるとハードルがとてもたかい気がします。

そういうむつかしい話はおいといて、実現可能ななんらかの方策を練る場合は、作成の手順として

１各当番のユーザーの記事はつねに１記事で、日程は毎月その記事の内容を書き換える。
　（基準と履歴となる情報は別にエクセルなどで日程管理しているものとして、WPはあくまで表示用）

２全ユーザーをまず表示する機能を作成する。そのうちで指定範囲内の日付をもっている記事については非表示にさせない。
　基準にみたなかった記事は随時非表示にする。
　または、表示せず全権列挙して、該当する記事は掲載させる処理をすすめる。

表示用データを読み込んでいる動作の最中にメタ情報を取得して、あたりならば対象の動作をさせる、という感じでどうでしょうか。
運用状況などにもよるとおもうのですが、管理なのか表示なのかでも構造がかわってくると思います。

おおまかに
○必要な項目数だけ抽出クエリで読み出したい。

というご要望について

●全対象を読み出して、各件整形して取り込む、または表示する際にメタをチェックして表示する、しないを決定させてみては。

という案になります。

抽出クエリをねりあげるまえに、対象の母数や範囲、記事の増減や履歴の扱いについてもうすこし把握できればよりよい方向性が求められそうな気がしました。

なるほど了解しました。
データの抽出母数はおおよそ１００件くらいということですね。
流動的なデータと固定的なデータが等しくメタ情報にについているようですが、消すというのはメタ情報を上書きするという認識でよろしかったでしょうか。

なのであれば、全件に対して抽出をかけて絞られた結果を受け取り表示するという方向から転換して、全件抽出して、いざ表示するという状態にもっていく際にひとつひとつメタ情報を確認してゆき、そこで条件にあわないものをふるいおとすという作業を考えるのはいかがでしょうか。
現在のデータ構成設計をとくに変更する必要はなさそうだと思います。

流れとしては

１）対象となる全ポストについて最低限の抽出を図り列挙の準備をする。（いろいろな記事を含めた全記事中の対象となる１００件のみに絞る）
２）列挙されるポストを表示または変数に取り込む際にメタ情報を取得する
３）取得したメタ情報を精査する
４）精査の結果適合しない記事については表示を完了させず次の記事にへ進行する

これを具体的にコードにして埋め込むとご希望の動作になりそうでしょうか。

将来的な拡張予定について機能的に潜在させたくクエリによる抽出を重要視するという場合は根本的にメタ情報を基軸とした設計のほうがよいと思います。
そうなれば、きっと外注を視野にいれられたほうがよいのではと思います。

ご検討くださいませ。

プログラムの利点は多様性にあって、クエリを使って抽出するのも多様性が長所です。
プログラムやクエリは、多様なデータが山積しているものについて非常に効果を発揮しますが、小規模のデータを整理するのにそこまで全力でかかる選択は不要な場合もあると思います。

クエリという表現については「抽出」全般行為にかかわることを示していまして、wp_queryをつかわれますと、ワードプレスの準備した定義での抽出になります。
イメージが共有できるとよいのですが、ワードプレスの準備した関数にて抽出を行う方法は、感覚的に「代理店経由」のようなものです。
直接phpのプログラムを使ってデータベースにアクセスし情報を抽出してくることもできます。この場合は「直接卸から仕入れる」ようなものです。
またそれらの中間をなす技術もあると思います。自由度が圧倒的に高い「卸」や、安定性、安全性の高い「代理店」で手間や安全性に差が出てきます。
「そういう出し方は非効率なのでうちではあつかっていない」という代理店や、「そこまでやるか」という卸の対応などを基準にどのレベルまで掘り下げるか選択肢があっても損ではないと思います。

むつかしい方の案ですと、ワードプレス自身がデータベースを読み取りに行くときの接続を利用して直接データベースからデータを抽出し、得られたIDで記事群を整形しようというものです。
クエリという命令文を使用して、データベース内部から切り分けたデータを取りだします。
今回クエリという命令にて小分けにしたデータでなくてはならないほど取り出し口が狭くないか、もしくは取り出すデータが巨大ではない、そのまま持ち出してから表示の直前で切り分けても間に合うのではないかと思った次第です。

クエリ、にも難易度高低があり、また作業的にもクエリを使用するしない、で高低がある、ということについては図などで経緯を説明しなくては、文字だけではよけいにややこしくなると思うので今回はそういうものだと思っていただけると幸いです。

工程がお決りになれば逐次必要なコードや設計について、助言をくださる方も多くいらっしゃると思いますのでがんばってください。