Вот мне и интересна эта область. Ты можешь ее описать?

Так оно и не может быть декларативным )
Собственно, с alter table вообще дофига проблем )

если на ORM надо делать логику - он хреновый

обычно меняешь модель, ORM сам тебе делает остальное, максимум переспросит только default value и т.п.

если ORM позволяет дополнительно делать логику - он хороший

Но вообще, формально, alter table как раз декларативный - и это проблема, так как нужно описать процесс добавления колонки и декларативность тут сильно мешает (

Эээ, вот "сам делает остальное" - это страшно, так как нет у него возможности это сделать. И информации нет.

Добавление колонки - очень опасная операция. Даже если это nullable.
А если у меня сервисы с разными версиями одновременно работают с БД (а как иначе), то там уже у ORMа большие проблемы )

Я сталкивался с ситуациями когда миграции писали руками.

Да только руками их и можно писать, как мне кажется.

Это было грустно.

Ну хз руками миграции не то чтобы менее страшно писать

Не, не спасет. Так как мне нужно уметь работать с разными версиями БД одновременно, что на ORM нереализуемо (обычно, я не видел исключений)

А ещё дефолтные данные в миграциях заливались.

Это совсем сложно.

Это лютая дичь. Ибо хрен пойми что в итоге в модели данных получается, особо если там таблички с метаданными для генерации других табличек используются.

Угу. Это даже руками сложно делать и нужен свой подход под каждую задачу

Я потому и люблю варианты с json - там миграции проще и выглядят более похожими. И менее опасными

1) Наверное только на некоторых языках, где все пишется так громоздко, что даже SQL с ручными преобразованиями входных/выходных данных выглядит компактно :))  Компактность - от того, что вы пишете на языке домена, и не пишете код преобразований и "перехода между мирами".
2) Это да. Мозаика часто встречается, и если SQL становится слишком много (больше 5 процентов всех выборок, например) - значит, явно что-то не то, и может ORM тут лишний.
3) Нет, это как раз работает всегда. Не всегда работают рефакторинги, если часть - на SQL, там придется руками дорабатывать. А вот проверки доменного кода - работают всегда (а его должно быть подавляющее большинство, см. п.2)
4) И еще раз - видимо, привычка к своему контексту. Вероятно, где структуры данных компактны, где много делается в памяти, где разнообразие комбинаций в выборках маленькое. Зато, наверное, объемы данных огромные, скорости тоже, критичность высочайшая и т.п.

Так все равно этот код приходится писать - в виде аннотаций, метаданных или что еще.
На каком языке получается проще, чем на SQL? Можно пример?

Вот в виде аннотаций и метаданных - это вариант с плохим ORM

3) Гм, как я могу перенести рефакторингом поле с одного класса в в другой? Это уже миграция и это нельзя делать как рефакторинг.
Так что рефакторинги проще не становятся ни на каплю, скорее наоборот.