Что касается того, что код должен быть ближе к данным,

я уже не вспомню, кто впервые об этом сказал, но это фундаментальный принцип=)
Он не может не работать. Просто его кто-то криво применяет.
Кто-то решил, что бизнес-логика должна быть только в одном месте, хотя это абсолютно не так. Не надо всё пихать в БД, или всё пихать в Java код.
Если на уровне базы данных полностью достаточно условий, чтобы провести бизнес операцию, не вижу смысла данные вытягивать на уровень Java кода, и там производить обработку.
Банально обновление данных, давайте рассмотрим.
Как сейчас многие пишут?
findById (id) -> object
setX
setY
setZ
persist(object)
Вот зачем так делать?)
1) Вам нужен лок
2) Если вдруг подвиснет, по какой-то причине, поток приложения, транзакция будет в idle in transaction статусе.
Да, постгрис можно сконфигурить, чтобы он через какое-то врейм убивал такие транзакции и отпускал тем самым локи. Но насколько настроите? На 1-2 сек?
А если у вас нагрузка 10K ops/sec ?:)
В данном случае да, можно удобно переписать на update set..., но это если одна таблица. А если их больше? Если взаимосвязь по целостности данных между ними? Итог: пишете хранимку.

Представьте, что у вас нет нагрузки 10К ops/sec, но есть сервер-сайд разработчики, умеющие в java делать так, что вероятность того, что "вдруг подвиснет, по какой-то причине, поток приложения" будет не больше той, что такой же поток подвиснет внутри PostgreSQL, и всё встанет на свои места.

Сегодня как раз читал, насчёт Postgres. Поэтому, не готов поверить, что все программисты Java такие:)) зато я знаю, какие реально Java программисты. Я не оптимист, я реалист.

Вы можете быть оптимистом или пессимистом, у нас свободная страна. Но java программистов в свои проекты нанимаю я, лично. Не первых попавшихся, разумеется. И, смею вас уверить, в моей команде, проценте тех java разработчиков, кто в курсе что такое транзакции и как избежать ситуации, когда у вас "вдруг подвиснет, по какой-то причине, поток приложения" внутри этой самой транзакции равен строго 100. "Покупайте наших слонов" (с) 😊

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

Это да. Но плата за это: 1. Распыление ответственности за конечный результат. 2. Дополнительные сложности с наймом. 3. Дополнительные сложности с поддержкой. ХП пишутся обычно на довольно маргинальных языках, где нет ни устоявшихся best practices, ни вменяемых статических анализаторов, вообщем там "каждый суслик - агроном". Напомните, кстати - в PG уже появились хотя бы packages для логики в БД, как в Оракле? 4. Необходимость синхронизации принимаемых архитектурных решений на один дополнительный уровень Итого: для меня (для меня лично, не для всего ЗШ) минусы решения "БЛ в хранимках" перевешивают плюсы.

Нет таких разработчиков. Это фантастика.