Observations

именно.

Ошибка преподавания и использования ООП в моделировании предметной области.

А надо бы "разобрать" предметную область на составляющие, и моделировать их.
а описание в коде предметной области - собирать их этих составляющих.

на примере обычного языка:

ООП сейчас часто применяется как:
видим в предметной области:
"... в наивном ..."
аха, вот он класс Naively
встречаем
"... в наивных ..."
аха, наследуемся
встречаем
"... это наивно ..."
аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.

встречаем
"... глупо ..."
новый класс

итого, получаем на вид описание предметной области, а на деле ее "хардкодинг"
и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.

а надо бы
1. либо проектировать от правил - части речи, падежи
2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов

то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области.
именно в этом суть совета строить не наследованием - B is A, а композицией: В has A

для примера - холивар Rich vs Anemic

3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.