インデックスと「論理ファイル」は同じものではありません。同じものと考えてはいけません。
IBM i は SQL が標準になる前からリレーショナル・データベース・エンジンとして世に出ていた（「IBM で一番歴史のあるデータベース製品」）ので、当然 RDB のインターフェイスとしては独自の実装をせざるを得ませんでした。
（逆に言えば、本質は同じものなので SQL が標準になってもすぐに問題なく実装できた、ということでもあります）
「論理ファイル」と「RPG による READ/WRITE/UPDAT/DELET」がその"実装"です。
おそらく、その当時の常識的な技術者たちに違和感のないように、「COBOL でデータセットを読み書きする」というモデルで実装されたのだと思います。
RDB で言う「テーブル」は「物理ファイル」と呼ばれました。
いわゆる「データセット」の各レコードを桁で区切ってフィールドとして扱うようなイメージで使えるようになっています。
リレーショナル・データベースの機能として、この「テーブル」に対して「射影」したり「選択」したり「結合」したりすることができる必要があるのですが、これを「論理ファイル」としていわば実体化しました。
「論理ファイル」というのはうまい言い方で、"実体"はなく「物理ファイル」を「射影」したり「選択」したり「結合」したものにアクセスしているのに、物理ファイルをさわっているのと同様に扱えるようになっています。つまり「READ/WRITE/UPDAT/DELET」でアクセスできたわけですね。データセットを扱うように、「射影」したり「選択」したり「結合」した基底「テーブル」にアクセスすることができるわけです。
（ちなみに、これは"ポリモルフィズム"ですね。Java のインターフェイスと同様です。こういうことからも IBM i が"オブジェクト指向"であることがわかりますね!!）
動的にデータを読む、なんて思いもよらない時代でしたから、インターフェイスは原則として静的（static）です。
あらかじめ定義してある「論理ファイル」をとおして、元の「物理ファイル」をジョイン（「結合」）したものや、フィールドのデータに応じて「選択」したデータ、必要なフィールド（カラム）だけのビュー（「射影」）などをプログラムで読み書きする、という仕組みになっていました。
余談になりますが、動的にデータを読む機能も "QUERY" として存在しました。動的にデータを読む、というよりはカンタンに照会プログラム・入力/更新プログラムを生成するもの、といった方がいいのかもしれませんが、「物理・論理ファイル」に対して動的に選択条件や結合条件を指定してデータを読み出す機能がありました。
つまり、現在の MS QUERY のようなものが AS/400 (1988年発表） より以前にあったわけです。その当時、データの自由検索をまともなパフォーマンスで行うというのは相当なことだったんです。
しかし、今や SQL が標準として確立されています。
COBOL によるデータセットの読み書きも、"いまどきの技術者の常識"とは言えないでしょう。
「論理ファイル」と「RPG による READ/WRITE/UPDAT/DELET」はもう歴史的な使命を終えたのではないでしょうか。
RPG でプログラムを書くにしたって、埋め込み SQL で書くのと「READ/WRITE/UPDAT/DELET」で書くのとでは実行速度に差はありません。（もしかすると埋め込み SQL の方が速いかもしれません。いや本当に）
「論理ファイル」の DDS による SELECT/OMIT、JOIN やフィールドの選択も、すべて SQL でできないものはありません。
逆に、DDS による選択/除外は常時メインテナンスされるアクセスパスがついてきてしまうので、基底テーブルが更新される度にシステムには負荷がかかっている状態になってしまいます。ディスク容量だってそのために余計に必要になります。（ビューは選択/除外条件のテキストだけなので圧倒的に少ない容量ですみます）
選択条件も多様化し、増えていく一方ですね。それに応じてたくさんの「論理ファイル」をつけてしまえばしまうほどシステムへの負荷は重くなります。動的に必要なデータを SQL ないしビューなどで取ってくる方がムダがありません。
あくまで「論理ファイル」は時代の産物で、インデックスやビューの代替にはなりません。
インデックスもビューもそれぞれ SQL の世界、最新のリレーショナル・データベース技術を反映して、すでに DDS で作った「論理ファイル」とは全然違ったものになっています。（試しに同じキーを指定して DDS で作成した論理ファイルとインデックスをそれぞれ DSPFD コマンドで属性を見てみてください。インデックスにだけ存在している属性があります）
同じものだと安易に考えるのはやめて、インデックスやビューへの移行を考えましょう。
論理ファイルをなくそう、ってったって、RPG で論理ファイルを使っている場合はどうするか、ですが、いろんな方法がありますよね。
埋め込み SQL に書きかえたっていいですし、選択/除外/結合の論理ファイルであれば OPNQRYF を使用することで RPG の書きかえはほとんどなしでもできますね。
いまどきの CPU パワーであれば、動的にデータを取ってくるのはそれほど時間のかかることではありません。↑ で言ったようにぶらさがっている論理ファイルのアクセスパスが常時メインテナンスされていることの方がメタボ的にシステム資源（CPU/メモリ/ディスク）を奪っている可能性がありますので、それよりは OPNQRYF で必要な時に必要なだけシステム資源を利用する、という方がいまどきでは理にかなっています。
DDS でできるようなことはほとんど OPNQRYF でできますよね。それ以上のことができたりもします。ある意味論理ファイルを置き換えるためにうまれてきたようなコマンドなわけです。（CPF 8.0 で登場してきた時はどうやって使うのかあんまりぴんときませんでしたが。。）
私のような S/38 あがりの技術者が「もう論理ファイルを使う積極的な理由はない」というんですから、くりかえしになりますが「論理ファイルを同じものだと安易に考えるのはやめて、インデックスやビューへの移行を考えましょう」。