Предлагаю, пока тут опять все не переругались, согласиться с постулатом: нет универсального и единственно правильного решения 2 звена или больше двух!
Каждый решает сам.
Давайте разделим области и попробуем сформулировать критерии, в каких случаях лучше применять 2 звена, а в каких - больше.
Плюсом обозначим условия ЗА применение конкретной схемы, минусом - ПРОТИВ.
Позволю себе начать немного ниже.
А для начала хорошо бы определиться с терминами.
Предлагаю следующие обозначения архитектур:
х[х]-[х[х]-х[х]]
D - хранение данных
L - реализация логики
I - интерфейс пользователя
Примеры:
1) D-LI - классическая двухзвенка, где данные в DBF (MySQL) без ХП, а логика совмещена с пользовательским интерфейсом.
2) D-L-I - классическая трёхзвенка, где логика вынесена в отдельный слой.
Мне приходилось сопровождать несколько систем вида DL-LI. Вот там с некоторого момента начинался сущий ад. Например, валидация данных была в GUI и дублировалась в БД констрейнами.
Пожалуй, соглашусь с мнением, что часть логики можно оставить в СУБД, а часть - более высокого уровня - вынести на сервер приложений (SOA). Вот только очень важно определить эту грань. Попробуем?
Ещё несколько моментов, которые вывел для себя, читая форумы. Каждая сторона может привести кучу доводов ЗА или ПРОТИВ. Давайте не будем о них спорить.
1. Современные СУБД типа ORACLE, MS SQL, PostgreSQL предоставляют достаточно возможностей для реализации любой логики на уровне СУБД.
2. Вопросы доступа, безопасности данных зависят больше от квалификации разработчика, чем от архитектуры.

Итак, для затравки:
* D-LI
+ предусматривается миграция данных на другую СУБД.
+ все клиенты в локальной сети.
- необходимость синхронной установки новой версии ПО на всех клиентах и БД.

iscrafmlogoutсервер приложений (SOA)
по какой причине вы это написали так, как будто SOA и сервер приложений являются синонимами? Что имелось ввиду?
SOA как способ организации более высоких уровней логики.