1) Абсолютно по-разному.
Бывает так, запустили проект, индексы не сделали. Их не сделали не обязательно потому что не разбираются в этом, а потому, что на этапе разработки проекта еще не было известно, какие отчеты захочет заказчик. Данных за неделю накопилось, проект стал тормозить.

А бывает так. Другой разработчик сделал какой-то полезный для бизнеса функционал, сделал джоб для заполнения новой структуры данных. Первые полгода все было хорошо, потом у нас стал тормозить импорт данных(первичные данные переформатировались и заливались в новую более удобную для анализа структуру). Источник проблемы был найден, но отключить(джоб) его уже нельзя. Данные функционал необходим для работы.

Запустили проект, несколько месяцев он работал. Даже не то, чтобы тормозил, но запросы по этому проекту часто попадали в список самых неоптимальных\медленных. Одними индексами там было не обойтись, надо было, для начала, поменять алгоритм работы проекта, т.к. делать индекс на текущей структуре было бы не правильно\не оптимально.

Ну и я ежедневно мониторю, какие индексы необходимы для запросов. В день по 2-3 индекса делаю, либо дорабатываю(меняю один индекс на другой). А то если втупую лепить индексы по статистике, то будет куча похожих индексов.

2) Мы не продаем ПО, мы продаем услуги(аутсорсинговый call-центр), т.е. вся система у нас внутри. Как такового релиза нет, есть просто заявки на доработку отчета\другие услуги. Как разработчик сделал, протестил по возможности, менеджер проверил, тут же это и применяется в системе.
Просто дело в том, что другие разработчики не разбираются в оптимизации SQL-запросов, но делают отчеты\другие услуги. :)
И если у нас тормоза, то нам нельзя ждать, пока разработчик разберется, поправит, иначе заказчик просто нас пошлет, если у него будет отчет грузиться по 10мин или скрипт сценария разговора у оператора по проекту будет работать со скрипом и клиенты просто будут бросать трубку. У нас даже небольшой простой системы\проекта очень дорого нам обойдется финансово.

В данном простом примере в результате будет выполнено 2 запроса, вместо одного. А если, например, этот запрос выполняется 1000 раз в секунду, в итоге будет 2000 запросов, вместо 1000.

з.ы. Запрос изначально кривой, с кривой логикой, странно ожидать, что оптимизатор постоит идеальный план. Он же не ИИ.

Безусловно. :)

Это в вашем случае использования ОРМ будет 2 отдельных запроса\метода, что как бы не очень хорошо!
В случае, если запрос вызывается редко хрен бы с ним, а если часто, то минус производительность.