авторА то мне программу, заточенную под конкретную СУБД, сложно назвать гибкой в сравнении с программой, способной работать с различными базами.
Почитайте статьи на Хабре, посвящённые сравнению универcальных решений, работающих с разными базами, и нативному SQL. Каждый из вариантов имеет свои плюсы и минусы. И каждый из вариантов применяется в реальных проектах.

Когда работал с универсальной ORM, вначале хотел делать всё "как положено". Но в итоге от этой самой универсальности отказался в пользу гибкости нативного SQL. Отказался по двум причинам: сам процесс генерации запроса занимает процессорное время и такие решения серьёзно связывают руки в плане построения индивидуальных запросов (в т.ч. с использованием нативных возможностей СУБД). Сейчас типовые запросы формирую с помощью ORM, индивидуальные - вручную, на чистом SQL. Либо типовой вложенный запрос или часть запроса - с помощью ORM, далее конвертирую в SQL и завершаю построение запроса чистым SQL.

авторВ соседнем топике я вам картинку, иллюстрирующую реальную оптимизацию большого запроса привёл.
Но тебе наверняка легче будет думать, что я её от руки нарисовал, чем в мой многолетний опыт работы с БД.
На основании одного запросы вы пытаетесь сделать какие-то глобальные выводы. Неправильно это.
Многолетний опыт работы с БД имеется у многих. В том числе и тех, кому приходилось работать с большими неоптимизируемыми запросами. Зачем пропагандировать крайности ?

P.S . skyANA , не уподобляйтесь hVostt'у в плане трёпа.