Функциональное программирование на PHP

Это зависит от программистов.

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

Спорить начинать не хочу на эту тему, про частности, про СУБД. А просто про нечто в вакууме скажу. Логика, написанная на уровень выше — не что иное, как конкурирующий сервер с тем, что ниже. Люди пишут велосипедище, причем опасное, с мегакостылями. Например, в базе данных декларативно моделируют с помощью связей — как должна проверяться целостность данных. Таким образом формируют некоторую модель предметной области. Но программистам на уровень выше — не нравится такая строгость и делают свой сервер, который ослабляет проверки или вообще уничтожает. Доходит до того, что думают, что СУБД вообще должна только хранить данные. Чушь несусветная. Если бы было так, зачем деньги тратить на СУБД? Оплачивать работу разработчиков оракла, майкрософта, которая вам не нужна? Если нужно только хранить данные — есть файловая система.
Вообще, принципиально, данные не должны дублироваться. Они должны быть в одном месте — один источник. Как бы есть принцип правильной разработки — не дублировать код, не дублировать данные. Когда люди пишут на уровень выше, то по сути, они дубрируют данные, создают механизмы синхронизации. Плохо всё это.

Данные и их обработка должны быть как можно ближе. Просто помечтайте, что СУБД не состояла бы из таблиц, а состояла из объектов и язык был бы ваш любимый (PHP, Java, C#). Вы бы и в этом случае выносили работу еще в один сервер сверху? Скорее нет. Теперь двигаемся на шаг дальше в воображении: такой гипотетический сервер на любимом императивном языке имеет смысл, если бы он мегаускорял работу с данными. Т.е. вы пишете на своем языке, а он умеет оптимизировать обработку большого объема данных. Хорошо было бы, но это невозможно в императивных языках. Тогда, дальше пытаемся представить: нужен какой-то язык, который бы ограничил работу как-то декларативно, чтобы сервер мог брать на себя работу.

Вот такой язык и есть SQL. Он ограничен, но благодаря этому, он позволяет легко изменять вычисления при любом требовании. Императивные (ООП) языки сделаны по принципу — пишем опасный код, который всё может, но чтобы смогли контролировать баги при росте объема кода — скрываем код — за функциями, за классами. Реляционные БД сделаны по другому принципу — создаем декларативно отношения, создаем ограниченный язык, который можно применять ко всем данным открыто, не боясь что-то сломать. Это функциональный подход по сути.

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