Ай, молодцы :)

И про передачу параметров вспомнили, и про идеальный язык дельфи, и С++-ников с гавном смешали. Знатный топик получился :)

Давайте, флейма ради, добавлю.

90% программистов (даже в java) не пользуются даже одиночным наследованием (обязательное наследование от специальных классов фреймвёрков в рассмотрение не берётся, т.к. делается на уровне "по другому нельзя"). Ещё 9% используют его "подмножествно" (да да: подмножество подмножества :)), а именно наследование от интерфейсов и наследование ради возможности осуществить полиморфный вызов (полностью описывается паттернами из разряда strategy или template method).
И только 1% программистов занимается задачами (разработка фреймворков, разработка для повторного использования, не тривиальные предметные области), где возникает реальная необходимость в применении чего-то отличного от инкапсуляции для борьбы со сложностью.

Т.о. 99% процентов программистов, рассуждая о наследовании, использует самодельные теории, которые никогда на практике не проверялись.
Откуда берутся эти теории?
Очевидно из открытых источников (таких как faq sun'a "почему в java нет множественного наследования?") и в соответствии с кругозором (в виде экспириенса в delphi/c++/qbasic (нужное подчеркнуть)).
Играет ли тут роль многолетний опыт работы? Скорее нет, чем да, т.к. всё зависит от самой работы (типа решаемых задач) и отношения к ней.

А что в итоге? Холивор :)

softwarer NotGonnaGetUs90% программистов (даже в java) не пользуются даже одиночным наследованием
Да ладно Вам. У меня довольно низкое мнение о "среднем дельфере", но если верить Вам, выходит, что "средний явер" куда менее грамотен.

NB! Если я правильно понял, под "пользованием наследованием" Вы имеете в виду "унаследовать собственный класс от собственного же класса" - так?

Я слегка гиперболизирую, чтобы мысль нашла более живой отклик, но суть именно какая. Только причина не столько в том, что "явер/дельфер/другое" не грамотный, а том, что задачи, где использование наследования не будет высосанным из пальца, встерчаются не так часто как может показаться.
И даже там, где использование наследования уместно, обычно достаточно одного "уровня" наследования, причём с явно обозаченной целью
(Сюда можно отнести создание "пограничных" классов/интерфейсов, через которые будует взаимодействовать различные части системы, определение родовых алгоритмов, конкретные детали которых задаются через наследования от классов с абстрактными методами или путём передачи объекта реализующего определённый интерфейс и т.п. Это, в общем-то частные, хотя и чрезвычайно полезные случаи применения наследования, которые имеют мало общего с понятием is-a или моделированием реальных отношений между сущностями предметной области)

К слову о пальце.
Наблюдал своими галазами иерархию глубиной(!) 20, отражащую, фактически, только классификацию контроллеров для обработки http-запросов.

softwarer
NotGonnaGetUsИ только 1% программистов
Дык вот, через месяц или два после начала его работы мы с ним вполне серьезно обсуждали структуру классов для выданной ему задачи. По его инициативе, и там было, над чем подумать.
Обсуждению, обычно, подлежит выделение сущностей и распределение между ними обязанностей для решения поставленной задачи. Само по себе наследование в этом процессе играет малую роль.

softwarerВидимо, он сходу вошел в этот 1%?
Согласно определению данному выше, в 1% входят те, кто решает достаточно сложные задачи. Значит, если ему дали такую задачу и он успешно с ней справился - значит вошёл :)