Для меня наследование это просто удобство ради удобства. Без множественного наследования,

это бесполезная вещь, но удобная. С множественным наследованием, это опасная, но мощная вещь.
Наследование можно реализовать по разному, но сути дела не меняет.
Композиция и интерфейсы более грамотная реализация ООП, на мой вкус.
А само ООП с наследованием, это ниша. GUI и подобных вещей, где мы реально можем комбинировать элементы. Для большинства задач, это не нужно и невозможно отразить реальность.
Потому что все программирование будет вертеться вокруг данных. Конечно всегда можно сказать что все объект, но на деле. На деле объектное мышление, красивые слова, не более. Разберем JSON. Где O это Object.
У нас есть ограниченное число данных и комбинируя их мы можем получить структуры, разные массивы структур и карты. То что назвали там объектом что то, просто для красивого словца.
Как и большинство вещей в ООП основанном на наследовании. Мы можем назвать данные хоть объектом, хоть компонентом, хоть чем угодно. Вопрос как мы с ними работаем? И тут у нас вопрос, а как мы с ними работаем? Java / D / C++ / C# у всех разное "ООП и наследование".
На практике кроме как сделать удобное масштабирование, создание формочек, я для ООП с наследованием не придумал. Ну то есть функционал кнопки базовой и поехали ... И то это не единственное решение.
А если вам доступен DSL, так и вообще не нужное.
Возьмем DART / JS или Python. Тут это понять еще можно, динамика, гуишка и прочие вещи, где да. ООП смотрится как хороший такой Костыль, необходимый. Есть конечно вариант ООП в духе Lua.
Но для обыденного человека, этот путь явно сложнее.
Только вопрос, а какой ценой? Ценой всего! Код становится легаси быстрее чем проект доходит до релиза.
Баги плодятся, сущности плодятся, контроль теряется. Это прямо стандарт. С множественным наследованием, это порой вообще сказка и магия, которую тяжело понять.
Я не против ООП и мне нравится 1 сторона ООП это встраивание, особенно в духе Го.
С другой стороны ООП с наследованием это очень простой путь, но ведет он чаще в помойку.
Но тут есть 1 плюс, это помойку можно неплохо рефакторить. При определенных обстоятельствах и в опредленных условиях. Удобно конечно взять Object и запихнуть что надо, наследовать что надо и поехали.
С другой стороны есть Any почти везде и без наследования.
Я могу придумать пару кейсов где наследование круто, но в большинстве своем не нужно.
Про реализацию я не просто так поднял вопрос выше, от этого зависит ВСЕ!
Перф, память, возможности, поведение. Банально то как вы будете подсчитывать матрицу в таблице ссылок.
С математической точки зрения пофигу как, а с точки зрения программы ой как не пофиг.
Тут начинается первые муки выбора... и так они идут до нашего с вами кода.

ну, теоретически-практически, я с вами согласен. ООП разное и в общем-то нашпиговано проблемами, решений который никто не знает. Я лично считаю, что для простых программ оно себя не оправдывает, как и там где есть крайне специфические требования в виде низкого уровня, перфа и т.п., нужны другие парадигмы, либо их смесь. Каждой задаче - свой инструмент. Наследование можно, конечно, развязать через композицию\агрегацию\ассоциацию. Допустим, не знаю там, рандомная игра имеет сущности человек и мы композицей добавляем ему хвост. Это будет работать ровно до того момента, когда не появятся, например, болезни хвоста, а хвост не наследуется от органа человека, который не наследуется от тканей, которые не наследуются от клеток человека и таким образом хвост не содержит клеток человека и ему нельзя добавить все их свойства и особенности человеческого воспаления\патпроцесса. Он будет требовать хаков, поскольку не является частью организма чела по смыслу модели, хотя раньше оно работало норм. Выходит такой же вид отложенных архитектурных проблем, как и навертывание иерархии от правки базовых классов. + траблы с проверками типов и т.п. что опирается на механизм интерфейсов\наследования\полиморфизма. Я, например, много раз наблюдал проблему от одиночного. Иерархию блокирует либа\фреймворк и тут в любом случае нужно юзать композицию, втюхивая объект в поле. Потом часть апи принимает совсем другой интерфейс, а другая часть апи требует массового доступа к методам вложенного, что требует меты\рефлексии\чтотовыдумывать как ему это все прокинуть. Эта превращается в большую проблему. Т.е. одиночное наследование может демонстрировать проблемы композиции в некоторых случаях. Но опять-таки, да, в каждом ЯП своя специфика.