Проблемы на границе сопряжения приложения и базы.
Описываемые проблемы есть и у тех, кто пишет SQL руками, и у пользователей ORM (возможно в меньшей степени).

Чем хороши ORM?
- не надо думать о соответствии типов в приложении и базе. Об этом подумали разработчики фреймворка
- не надо думать о консистентности схемы и запросов. Если схема изменилась и запрос перестал соответствовать схеме, вы узнаете об этом прямо в IDE
- кодогенерация

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

Насколько это большая проблема?
На мой взгляд, довольно серьезная.
При изменении базы или запросов спасти смогут только интеграционные тесты.
Если они очень подробно написаны. Особенно fail-кейсы.
Но это не точно...

Что может пойти не так?
Для результатов запросов можно выделить несколько проблем:
1) Изменятся типы полей
2) Изменится nullabitity
3) Изменится класс количества строк в ответе
4) Изменится логическая связанность полей
5) Изменится порядок строк

1) Изменятся типы полей
Типы полей в результатах могут смениться по нескольким причинам. Например:
- изменился тип исходной колонки в схеме БД
- изменилась функция или выражение для вычисляемого поля (или их параметры)

Возможно, это сразу будет выявлено при тестировании. Например, в js изменение INT на BIGINT или FLOAT приведет к изменению типа с number на string внутри приложения.
Представим, что с данными ничего не происходит внутри приложения, а они всего лишь отдаются во внешние сервисы.

При этом рантайму все равно что там за тип вернула база (js, python и тд).
Можно представить что может произойти при недостаточно строгих тестах...

Или еще вариант: BIGINT преобразуется в строку. Но внезапно вместо числа в строке мы начинаем получать произвольный текст.
И даже если у нас есть json-schema, которая используется в тестах, мы скорее всего ничего не заметим.

Т.е. либо мы должны иметь очень строгие тесты, либо очень внимательных инженеров на круглосуточном дежурстве :)

2) Изменится nullabitity
Почему такое может произойти?
- изменилось ограничение на NULL у исходной колонки в схеме БД
- добавился или исчез внешний ключ между таблицами при JOIN
- изменился тип JOIN
- изменились условия фильтрации в оригинальном запросе или вложенных запросах

Например, если удалили внешний ключ, по которому производится LEFT JOIN, то уже нельзя будет гарантировать то, что вместо присоединяемого значения мы не получим NULL.
Аналогичная ситуация возникнет, если внешний ключ есть, но JOIN изменили на LEFT JOIN.

Изменившиеся условия фильтрации так же могут влиять на nullabitity:
SELECT (SELECT 1 WHERE TRUE)
vs
SELECT (SELECT 1 WHERE FALSE)

Это будет проблемой во всех языках, кроме, наверное, Java, где ожидаемо, что любое поле объекта nullable :)
Результат - много 500ых ошибок в логах...