Может быть. Но я про то что ОРМ, как по мне, это про то как маппить данные из хранилища в  в модель с которой ты работаешь в коде. К примеру, можно взять любую слоеную архитектуру в которой есть отдельный доменный слой, которая ничего не знает про хранилище. Задача взять данные из хранилища и передать в доменную модель. Но доменная модель может работать только с предопределенной структурой. Так вот дальше ты пишешь маппер для перегона данных из вида хранилища в вид понятный доменной модели. Но , а если у тебя таких структур много. Ты же не будешь писать каждый раз отдельный маппер. Хочется что такое написать что будет маппить вместо тебя на основание, как вариант, мета данных. Так вот это, как по мне и есть орм. То что в орм под капотом там уже юзаеться всякие юнити оф ворк, индетити мап , генерятса запросы И так далее, это уже детали реализации.  Да и запросы ты же сам можешь писать, не обязательно вместо тебя это должна делать орм. А потом орм тебе поможет замапить на структуру которая тебе нужна.

Но это мое мнение, у меня нет цели спорить и доказывать что это только так и ни как иначе.

Так и я про то же ) Отчеты, из примера, это не про ОРМ, конечно (ну если только реально маленький отчет и задача\система позволяет). Для них отдельный сервис со своей БД, ну и обработка данных ближе к данным - через тот же постгрес можно в принципе даже Excel-ки выдавать..

Без орм читаемость и понятность гораздо выше

Объектная модель доменной области это зло, ООП не подходит для моделирования объектов реального мира

Естественно, ведь реальный мир состоит из чистых функций, а не объектов (ООП в глазах смотрящего)

А какие есть альтернативы?

Тимур, вы сейчас всю картину мира людям свернёте ) вообще, моя практика пока подверждала тезис "абсолюта нет"

Для меня удобство орм заключается в возможности путешествовать по графу объектов бд
user.folders.forEach(folder=>
folder.project.forEach(project=>
 project.tasks.forEach(task=>
  task.comment.forEach(...)
И в точно также получив по айдишнику объект комментария можно по обратным ссылкам пройтись до объекта юзера -  db.comments.find(id).task.project.folder.user

Это на порядок удобнее так как не нужно думать в терминах sql о том какие джойны или подзапросы нужно выполнить, или какие объекты по каким айдишникам маппить (как в монге или других документных бд)

Бросаем всё и переходим на модель акторов)

удобно, безусловно. но не согласен, что не нужно думать в терминах SQL. Всегда надо понимать ресурсоемкость получающегося запроса и сопоставлять с задачей. А то может оказаться, что запрос выполняется минуту а то и десять на "пустом месте"

Вот эти две лекции посмотрите
https://youtu.be/Wb7o_kK4aH4
https://youtu.be/r4ReQlVtfgQ

Выучить sql слабо? Без знания реляционной алгебры будет только говнокод

О вкусах дерьма не спорят

В большинстве случаев нужны три вида джойнов.
И нода скорее про микро (нано сервисы) а не про огромные монолиты. Где нужно городить запрос с адовой тучей вложенности.
Простые структуры - понятные запросы.
2-3% случаев когда правда нужно что-то тюнить

Обоснуйте по ноде

Так холиварная тема.

соглашусь. о вкусах вообще, а дерьма уж подавно )  но здесь, думаю, уже религия. а о ней тоже не спорят..

ссылки на науку прислал выше

Спасибо, гляну

А рыночек ещё не порешал разве? Оставив за нодой bff, микросервисы и mvp
Не, написать то на ноде можно всё, кто-то её и в iot тянет. Но большинство применений, естественная ниша, разве не ограничены вот этим, перечисленным выше?