ORM - это все же не про миграции. Притянуто за уши.
Давайте скажем "при разработке с применением SCRUM миграции не прошли и данные пропали, опасайтесь SCRUM"

А что за ОС?

какой-нибудь CompCert ?

Эмм, а управление объектной моделью это не про ORM?

Миграции - это инструмент управления обьектной моделью в хранилище. Почему вы считаете, что это настолько слабо связано?

Я к тому, что как говорит @dphil это про особенности процесса разработки, когда один и тот же джавист, пыхер или питонист пишет и ORM обращения, и миграции и ещё там что-то рядом делать пытается.

> Но я все равно не понимаю, зачем может быть нужен ORM.
Это лишний текущий слой абстракций, который в некоторых простых случаях уменьшает затраты из и так не ресурсоемкой части разработки, но добавляет кучу проблем.

Чем объемнее структуры данных (не хочется говорить "сложнее", т.к. со сложными ORM не справляются), и чем больше разнообразных операций над ними, особенно выборок, и чем более "рядовые" разработчики у вас, тем ORM выгоднее. Прикладной код становится значительно компактнее, boilerplate исчезает, масса ошибок исключается на этапе компиляции, легко добавляются и инкапсулируются общие схемы хранения сложных значений, запросы при этом часто вполне приемлемы по качеству, скорость разработки вырастает, гладко работают рефакторинги в IDE, абстракция хранения протекает несильно, надзор над SQL нужен не очень большой.

Смотри, у тебя ORM реально мешает миграциям, так как зависит или от модели БД (одной) или вообще кодогенерация по базе.
И поэтому процессы миграции БД сильно завязаны на работу с ORM и сильно ей ограничены и, обычно, сделаны в ORMе очень фигово.

На чистом SQL оно попроще )

А в каком мире без орм теряется привязка к бд?

Похоже пора доклад делать...

Не понимаю. Миграция не может мешать ORM в принципе (и наоборот), т.к. ORM - это часть дизайна функционирования, а миграция - это дизайн перехода с версии на версию. Они ортогональны в определенном смысле. Если ты смог перейти от дизайна 1 с ОРМ к дизайну 2 с ОРМ - если смог! - то как уже может что-то помещать ОРМ работать в дизайне 2???

Типичные ошибки применения ORM фреймворков.

Хм, вот тут много вопросов.
1) Почему код становится компактнее? Добавляется куча кода на ORM, который совсем не компактнее SQL
2) Какой бойлерплейт исчезает? Скорее добавляется куча дополнительной фигни вылезает и дополнительных сложностей. Абстракция то протекает постоянно.
3) Компиляция тут не при чем, так как все равно есть зависимость кода от БД и ничего не изменится.
4)  Скорость разработки обычно падает, так как добавляется борьба с ОРМом и его ошибками/неожиданностями.
5) Рефакторинги вообще приходится делать руками, так как правки в коде не связаны с БД и приводят к проблемам с миграцией.

Т.е. все ровно наоборот, сложность вырастает, а толку - нет.

> На чистом SQL оно попроще )

это у вас ORM нормального не было

У меня всякие были. А нормальный - это какой?

(Вообще, по моему опыту, для реальных задач лучше всего подход с json-полями и сериализацией. Там все и просто и эффективно выходит. Но это уже отдельная тема).

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

Но вообще работа с БД обычно где-то 1% от трудозатрат (3-5%, если с миграциями и требованиями выкладки без останова на распределенной системе). Там ORM вообще нефига не экономит.

Мне кажется что тут описан прокси к sql базе)

Пример конкретного решения есть?
И что значит "произвольный код на другом языке", при чем тут ORM?