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

Кроме Java EE есть и другие фреймворки, например, https://spring.io/ Там все гораздо лучше.

> В плюсах всегда был возможен другой стиль - когда наследование используется минимально,

Использование наследования вместо композиции - это вообще антипаттерн,
для Java нормальным вариантом является именно что композиция, а не наследование.
подробнее об этом написано в http://www.ozon.ru/context/detail/id/6108824/

В плюсах не всегда возможен другой стиль, и это одно из тех мест, где Java
значительно лучше плюсов - в Java есть интерфейсы и есть nested классы,
так что множественное наследование не нужно вообще, интерфейсы и вложенные
классы с этим полностью справляются, причем гораздо более элегантным способом.

В плюсах вообще все делается через наследование - и имплементация интерфейса
и наследование поведения, что не способствует понятности плюсовых исходников.

Поскольку интерфейсы в Java оказались очень удачной идеей -
эту же идею потом реализовали и в новом гугловском языке программирования Go.