stenford, вот вам входные данные:

Есть исторический справочник, размер таблицы 200Гб (да, именно таблицы :) ). Нужно получить состояние десятка объектов из этого справочника на дату 2000/01/01. Сам справочник организован как через таймштамп модификации поля с величины А на Б, для начальной точки реализовано через признак создания, таймштампы созданий естественно разные. У вас в наличие 3 аппсервера, по 64Гб RAM на каждом, БД с 128Гб RAM, шкаф хранилища на оптике RAID 10 на HDD. Ну и можете теперь рассказать о преимуществах ORM для данной конкретной задачи, либо предложить решение без того чтобы крутить данные сервере баз данных.

* И это только один такой пример, а ведь в реальности их очень даже много... Чего только импорт/экспорт (ETL), аналитика стоят. Повторю свою мысль еще раз - ORM хороши для маленьких/средних задач, но как только решение вырастает, то тут уже отсутствие возможности ювелирной юстировки какой-либо из частей системы - это минус, при этом минус серьезный. Ну и в критически важных местах, где требуется действительно хороший отклик - места ORM тоже нет. ORM это так - решение типичных задач, типичными способами, за среднее время. Т.е. просто ширпотребное решение, не дающее особых плюсов, но помогающее избегнуть типичных проблем и понизить планку требуемых специалистов.
** Написанное выше - личное мнение, исходя из собственного опыта работы как с различного рода подходами, как комбинированных так и без ORM или исключительно ORM-ориентированных. Собственно мое текущее мнение простое - набросать каркас, заготовку можно с использованием ORM, ну а как в жизнь пойдет, то быть готовым, что очень многое нужно будет либо выкинуть, либо переписать еще и казня себя за то, что сразу нормально не делали, а связались с кодогенерацией ORM. :)