История изменений

Так не бывает. Не учитывается много специфики, навскидку: уровни изоляции транзакций

Это не важно, т.к. всё укладывается в стандарты JDBC.

гигантские различия в синтаксисе SQL

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

области (страница/ряд/поле) и условия действия блокировок/дедлоков, версионник наша СУБД или блокировочник

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

организация сессий, AutoInc/генераторы/rowid или что там, есть ли евенты, несты, возможности хряп, триггеров.

От всего этого и абстрагирует ORM.

Если все это усреднить до «выбрал СУБД в настройках», то отвалятся почти все возможности SQL.

Это правда, 99% из мануала никогда не будет использовано. Всё, что от SQL в современных системах надо - хранение коллекций туплов с foreign key-ями и быстрое выполнение простых запросов по этим туплам.

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

Ну во-первых обычно такого не происходит при грамотной архитектуре. Во-вторых пока БД сервер отдыхает, душа архитектора радуется. Потому что засовывать HTTP-серверы в кластер на порядок проще и безопасней, чем раскластеризовать СУБД.

Те самые проблемы из-за таймингов на сложной логике + стремительный рост вероятности дедлоков. Да что там говорить - планы запросов смотреть/править приходится и сокращать длину транзакций, насколько это возможно - это не алгоритмизируется.

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

По факту, если на проекте есть человек, который следит за отсутствием бардака, бьёт по рукам любителям SQL, проект достаточно быстро может быть переведён на другую БД. Посмотри на Jira. Проект большой сложности, при этом используется огромным числом организаций, поддерживает множество пользователей, кластеризуется, работает довольно шустро, и при всём при этом вполне нормально поддерживает кучу разных БД.

Так не бывает. Не учитывается много специфики, навскидку: уровни изоляции транзакций

Это не важно, т.к. всё укладывается в стандарты JDBC.

гигантские различия в синтаксисе SQL

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

области (страница/ряд/поле) и условия действия блокировок/дедлоков, версионник наша СУБД или блокировочник

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

организация сессий, AutoInc/генераторы/rowid или что там, есть ли евенты, несты, возможности хряп, триггеров.

От всего этого и абстрагирует ORM.

Если все это усреднить до «выбрал СУБД в настройках», то отвалятся почти все возможности SQL.

Это правда, 99% из мануала никогда не будет использовано. Всё, что от SQL в современных системах надо - хранение коллекций туплов с foreign key-ями и быстрое выполнение простых запросов по этим туплам.

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

Ну во-первых обычно такого не происходит при грамотной архитектуре. Во-вторых пока БД сервер отдыхает, душа архитектора радуется. Потому что засовывать HTTP-серверы в кластер на порядок проще и безопасней, чем раскластеризовать СУБД.

Те самые проблемы из-за таймингов на сложной логике + стремительный рост вероятности дедлоков. Да что там говорить - планы запросов смотреть/править приходится и сокращать длину транзакций, насколько это возможно - это не алгоритмизируется.

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