Много уровней абстракции тянут за собой более-менее стандартный набор - фабрики, медиаторы, фасады, прокси и т.п. - всё, что отвечает за то, чтобы не утонуть в громоздком коде. Как по мне - они очень замыливают глаз в плане понимания "а что мы тут, черт возьми, хотим сделать" - особенно когда тыкаются в глаза в названиях классов и методов. Туда же - запрет иметь классы-реализации без абстрактных классов, попытки конфигурировать то, что никто и никогда не будет менять, вроде используемого движка БД... Оно, насколько я опнимаю, пошло из библиотек джавы, которые, во-первых, должны быть универсальными, а во-вторых - рассчитаны на работу в раках стека Java EE, что автоматом подразумевает монструозность приложения, в-третьих - результат бедности (особенно в прошлом, когда традиция и появлялась) джавовского синтаксиса.

В плюсах всегда был возможен другой стиль - когда наследование используется минимально, зато в ход идут STL, шаблоны, перегрузка, стековые объекты, сейчас еще auto добавилось - в результате в софте небольшого масштаба (скажем, на пару сот тысяч строк) можно иметь более-менее читабльный код именно в  плане понимания "что делаем".