Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).
Кроме того ORM, как правило не исключает обращение к БД на уровне произвольных SQL запросов, оно лишь преобразуют результаты этих запросов в объекты модели предметной области (и наоборот), которые ничего не знают (в идеале) о таблицах, WHERE, HAVING и т. п.
ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().
