Da stimme ich dir nur bedingt zu, meine Erfahrungen sind da andere.
Der Exists wird wohl etwas anders implementiert sein und bietet mir bei Verwendung eines Index bisher immer das beste Ergebnis.

Kritisch sehe ich auch diese Angaben
"1 Access path(s) used for bitmap processing of file CHTRNP."
Dies ist für kleinere Dateien lohnenswert, für größere wird es problematisch. Ursache könnte der order by sein.

Wahrscheinlich ist auch, dass der Sort entfallen kann, wenn für die Order by Felder ein Index vorhanden ist. Das hängt im Endeffekt auch vom gewünschten Ergebnis ab.
Ohne Index muss ja erst mal alles eingelesen und sortiert werden.

Was ACS/STRSQL angeht, so habe ich die Variante mit "optimize for 1 rows" auch schon probiert (in verschiedenen Releases), konnte aber bzgl. des Vergleichs zu STRSQL da auch nichts verbessern.
Da laut Trace auf der IBM i (PCSACC/400) der SQL nicht verändert wurde, kann es "optimize" einfach nicht sein, es muss noch eine andere, undokumentierte Funktion (ggf. CLI-Attribute) sein, die man außerhalb von CLI nicht erreichen kann.

Bei den "ALL ACCESS PATHS..." Nachrichten kann man per F1 prüfen, welcher Index denn im Endeffekt verwendet wurde. Dieser kann und muss nicht der günstigste gewesen sein sondern wurde als "geringstes Risiko" ausgewählt.

Beispiel "in":
Hier ist eine Or-Klausel im Spiel, die beim Zugriff zu mehreren Sätzen führen kann.
Existiert ein Index über OHDISC und ein weiterer über OHDLRC als auch über OHTRNP der betroffenen Tabellen?
Wenn nein sollte man da über einen Exist nachdenken und Indizes erstellen.