давай проанализируем этот интерфейс.
1) что возвращает метод - множество записей. Но! в клиенском языке нет множества записей, а есть коллекция объектов. внезапно, да?
- думаем А подразумеваем Б. т.е. абстракция есть, а реализация размазана копипастом
2) такой же объект может возврашаться не в коллекции, а один, т.е. User::getUser. т.е. уже 2 места с одинаковым кодом, где происходит трансформация. ну ладно куй с ним напишет что-то вроде getUserFromSQL
- но еба, этим то все не ограничивается, см. далее:
3) User::saveUser (да, постфикс лишний, контекст определяет. определяет ведь? да? или User::save сохраняет жирафа? но к это чуть ниже). Что? опять трансформация только в обратную сторону? ну и пох, напишем руками
- и таких 2000. как во владивостоке? ну и пох - наше дело маленькое, мы ведь программисты, а не маги волшебники
4) хм, а ведь User::getList тут должен возврашать пользователя "просто пользователя", а там - пользователя и связанные с ним сущности, причем не только 1-1. да и пох, напишем User::getListFithPosts, добавим еще скуэля

...
N) у пользователя добавилось булево поле "использует ли он ОРМ"
- и нам придется...

перехуярить во всех местах скл и говнокод для работы с ним, сделать там несколько опечаток, заепенить этов git, выслушать от коллег какой ты пидорас.
и, естественно, это не протестировать.

и это только маленькая толика.

вот тебе и мощь ООП. это называет копипастный говнокод

а мне и с мегамэтрами не влом вести этот диалог. я в свое время так и научился

а мне приятно видеть что и в .NET (там можно всяко, но везде или EF, или NH или еще что-то) и в Java (Spring, и не только) этот подход культивирован. наверное у дураков мысли схожи.