[x-yuri]

Многослойные (наследованные) городушки неотъемлемая часть ООП

вот потому так и живем такие что ли?

Вау, это я не понял мне определение нужно дать что ли?

ну что значит должен? Мне интересно, что ты подразумеваешь под архитектурой. И чем она отличается от дизайна

1. Повторное использования кода

ну скажем так наследование реализации не очень правильно, но бывает удобно. Но дело не в этом. Если функциональность используется только внутри объектов, есть агрегация. Если нужно предоставить функциональность во внешнюю среду, есть... назовем это миксинами, что-то типа

mixin(Obj, Observable);

а наследование провоцирует спихивание общей функциональности вверх по иерархии, в результате чего, чтобы узнать, что делает метод надо лазить по этой иерархии вверх-вниз и обратно. При агрегации это не так актуально, так как наследование - более тесная связь, т.е. оно увеличивает связанность (coupling), что есть не хорошо, особенно для "больших стационарных приложений"

2. Управления объектами

что имеется в виду?

3. Управления поведением объектов

что имеется в виду?

4. Принцип абстракции

Динамическая "утиная" типизация по определению представляет собой полиморфизм. О чём тут ещё говорить.

пока что сложностей с синтаксисом не видно...

Вообще наследование призвано отразить иерархичность реального мира.

ну к чему этот довод, наталкивающий на мысли о религиозности собеседника?
Можно еще Александра Степанова вспомнить (разработчик STL если чё)

I think that object orientedness is almost as much of a hoax as Artificial Intelligence...

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.