не совсем

от ORM главное - декларативный подход
обычно приложениям не нужна вся мощь возможностей субд
зато код, оформленный с использованием ORM - намного читабельнее, и допустить ошибку при обновлении значительно сложнее

нормальные ORM также забьют тревогу, если текущая схема в базе отличается от того, что описано в коде

что позволит избежать косяков навроде "на тесте протестировали ок, на проде повалилось"

1) Код на ORM обычно сильно компактнее.
2) Там, где ты вынужден вернуться на уровень SQL, там ORM ничего не добавляет - ты просто возвращаешься к старому "доброму" SQL с параметрами, ручными преобразованиями, кучей "хелперов", и т.п. То есть к тому наилучшему объему кода, который ты можешь сделать без ORM.
3) Компиляция очень даже при чем, т.к. без ORM у тебя много шансов сделать ошибку в SQL и выявится это только при запуске. А на этапе компиляции ORM тебе, например, подскажет, если ты где-то дату со строкой решил сравнить (ну, к примеру), или просто пытаешься к отсутствующему свойству обратиться или опечатался. Собственно, это выявится еще ДО компиляции - в IDE, фоном.
4) Если вы тратите много времени на борьбу с ORM, значит, вы его применяете неправильно или там, где его применение не оправдано. Борьба с ORM должна занимать не больше процента вашего времени разработки. Типа, три дня в году на команду из 5 человек.
5) Многие рефакторинги делаются практически автоматом и порождают миграции, которые не нужно править, только короткий review (который всегда нужен).

Ну вот вы явно смотрите только на свой контекст, а обобщаете до любых.
А где-то работа с БД - это 30%.

жило-было приложение "энторнет-магазин", корзина и каталог в одной валюте

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

при миграции создаем сущность (таблицу) с курсами
и идем за историческими данными в какой-то сервис
чтобы не грузить xml или еще что с курсами за 10 лет, можно написать функцию, которая сходит, заберет, и заполнит таблицу по вчерашний день

Ещё раз озвучу тезис за который считаю правильным.
ORM - хорошо применим там, где нужны быстрые прототипы. Мало критично качество разработки и нет серьезных рисков при потере данных, косяках с переходом между мажорными версиями компонент.

В других случаях дешевле разделить работы между разработчиками отдав на уровень прикладной логики API бд предоставляющее CRUD над хранимыми объектами и аналитику.

Ну, примеров потери данных из-за ORM пока так и не было озвучено...  Миграции - это не ORM.
Поэтому непонятно, почему "только прототипы".
Здесь интересно: @dphil говорит, что всегда ORM лишнее, то есть он не видит преимуществ даже для прототипов.
Вот почему так?

ORM - как любой инструмент, имеет область адекватного применения.
И в центре своей области - он король.
Ну, а если кто-то работает исключительно в другой области, то, наверное, будет недоумевать.

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

ну а там где он не нужен, его и нет, никак не пойму зачем хейтить, со временем все перепишут, а "низкоуровники" останется в ниши ИТ магов, когда все ИТ просто будет считать их архонтами, а себя адептами, которым и знать то не нужно как омниссия работает.

Уточните пожалуйста, почему считаете миграции не относящимися к подходу к разработке с применением orm?

Хм, так SQL тоже декларативный

"нормальные ORM также забьют тревогу, если текущая схема в базе отличается от того, что описано в коде"
А вот это как раз страшно )

ALTER TABLE - нет

Я описал выше. Они ортогональны. Может быть одно любое из этой пары без другого. Разные задачи. Разные функции. Входы и выходы разные. Названия разные. Да что вообще у них общего???

должна быть таблица, три колонки, var, var, bigint ЯСКОЗАЛ - декларативно

обнови мне табличку добавь колонку bigint - императивно

1) Э, с чего бы? Запрос  на sql обычно и компактнее и проще читается.
Откуда компактность?
2) Поэтому приходится поддерживать оба подхода все время. И это грустно.
3) Это работает только если вообще нет ни строчки SQL в продукте, а так не получается.
Как только есть, то все, компиляция уже ни от чего не спасает.
Ну и, вообще говоря, валидация SQL-строчек по базе можно сделать (и нужно сделать) и без ORMа )
4) Э, я бы сказал, что вся работа с БД должна занимать около процента от общего времени разработки. Если больше - то что-то не то.

А что за контекст? Я плохо себе представляю такой продукт, зачем там так сделано?

Впрочем... наверное я тут неправ. Миграции - это все-таки часть широкого функционала ORM.
Но часть опциональная и точно не центральная.
Если единственное, что вас парит в ORM - это риски тех миграций, которые вам генерит инструментарий ORM - ну не используйте их.
Это лишит вас процентов 5 пользы ORM, остальные 95 - останутся.

Мне кажется, что смешалось понятие orm как стиля разработки исходного когда программного модуля и подхода к разработке систем.

В первом случае - да, это разные штуки живущие относительно отдельно.

Во втором - взаимодополняющие друг друга технологии.

Я не встречал пока одно без другого.

И где тут ORM? Тут про логику миграционных скриптов, которую как раз на ORM делать неудобно.