Лучше прочитать 912620 - FAQ: Oracle indexes прежде чем придумывать

Структура запроса с FAE и хинтом не особо отличается от структуры такого же запроса с ренджом. (По плану выполнения - вообще не отличается)
Если посмотреть аналогичный запрос сформированный по ренджу, то там SAP разбивает это условие на блоки, соединенные через OR, в итоге получается запрос вида:

Т.е. рендж нам подкладывает свинью, вставляя OR в казалось бы единое ограничение. К тому же указание большего количества SAP игнорирует, останавливаясь на тысяче(из ноты - the technical maximum blocking factor is calculated for each statement, so that no database system limits are exceeded).
Получается, что если будет указываться 1к+ значений в ограничении - выгоднее делать выборку через FAE, т.к. это и от возможного дампа убережет(при "раздутом" рендже), и по факту может быть быстрее.
Может кто более детально объяснит, в чем может быть опасность указания в FAE значений больше дефолтных 5? Т.к. на форумах и в нотах много где пишут что указывать числа, отличные от дефолтных нужно с осторожностью, но по трассировке ничего опасного я не вижу.

Касательно сабжа, решил подойти с другой стороны, т.к. крутить эту таблицу можно долго, но достигнуть действительно быстрой выборки будет тяжеловато. Да и не совсем подходит её структура для необходимой нам логики. Пока целевой вариант - добавить 2 поля в таблицу с данными объектов(дав осмысленные названия), и при переводе в один из статусов сохранять дату перевода в соответствующее поле, а уже потом по ним просто выбирать. В итоге у каждого объекта там будут находится всегда последние даты перевода в статус. Старые записи обновить через доп. утилиту.

А нельзя пересмотреть сам подход к запросу и вовсе избавиться от all entries in lt_objects? У вас ведь скорее всего где-то чуть выше есть запрос, который который сформировал этот самый lt_objects. Значит можно проблемный запрос превратить в JOIN, где в качестве второй таблицы указать данные выборки, которые которые сформировали lt_objects.