А если это чёрный юмор такой (про петлю Балмера помните) ? Великий Э. Дэйкстра указывал: «…то, о чём общество ИТшников в большинстве случаев просит — это 'эликсир' от всех болезней. Естественно, 'эликсир' имеет очень впечатляющие названия, иначе будет очень трудно что-то продать: 'Структурный анализ и Дизайн', 'Программная инженерия', 'Модели зрелости', 'Управляющие информационные системы' 'Интегрированные среды поддержки проектов' , 'Объектная ориентированность', Реинжиниринг бизнес-процессов…»

А что за другая версия ООП?
Как известно стало, что авторы нашли ошибки, но боятся сказать поклонникам, - этот факт через непубличные каналы, из уст в уста, среди не-поклонников, передаётся? Как избирательная простуда?

Пруфлинк, если не верите https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html

Ну явно школу троллей прошёл Нонаме. Расчёт на то, что никто по ссылке не заглянет, а если и заглянет, то читать не будет. Текст длинный

Передаётся конечно же. Читайте классиков - Буча, Дейкстру, Вирта, Бруккса, Кастанью. И даже в языках видно, ООП в Java допустим отлично Python, как отличались парадигмы симулы и смалтолка. Как говорится любой лектор (или как модно сейчас техноблогер) не говорит ничего особенного, он лишь умело монетизирует нежелание и лень слушателей самообразовываться и искать знания самостоятельно...

The second reason is that what society overwhelmingly asks for is snake oil. Of course, the snake oil has the most impressive names —otherwise you would be selling nothing— like "Structured Analysis and Design", "Software Engineering", "Maturity Models", "Management Information Systems", "Integrated Project Support Environments" "Object Orientation" and "Business Process Re-engineering" (the latter three being known as IPSE, OO and BPR, respectively). The external pressures to do the wrong thing are enormous, but yielding to them would be fatal for the academic enterprise, while resisting the pressure reinforces its strengths. The pressures are, in fact, so strong that I do not know a university where there is not some faculty or some department that has yielded, but there should be no mercy for snake oil pedlars on campus. [When a professor is no better than James Martin, he should start a business instead.]

Этот параграф может иметь миллион разных интерпретаций, как религиозные тексты.

На самом деле всё проще. Человек имеет ограниченные когнитивные способности. Прикладную ценность имеют только инструменты/технологии доступные широкому кругу людей. Другие, не "демократичные" инструменты/технологии используются главным образом в академической среде или небольшими группами особо увлечённых людей. Беда академизма в том, что часто трудно отличить работы имеющие ценность, от результатов мозговой мастурбации.

Я прочёл) только там текст логичен и последователен, с интересными, но очевидными наблюдениями и метафорами, а не вот это вот: "я раскрою вам всю скрытую правду", как пациент путанно передаёт.

Любопытно. И какие выводы?

там в целом о противостоянии университетов, как институций, против мирян с бизнесменами. О роли университетов в жизни людей, и какие там люди внутри работают, неся традицию сквозь века. Как они опасны и одновременно спасительны для общества. Философского настроя эссе от Дейкстры.

По диагонали посмотрел, поискал ключевые слова из контекста обсуждения. Не нашёл.

Угу, я тоже пытался) Предположу, что суть месседжа оракула в том, что ООП - это поделка на продажу любителям простых решений. И нет никакого единого и правильного ООП и быть не может. (таже логика для ФП, имхо).
Абзац, скопипащенный сюда из Дейкстры, примерно это говорит (макая в лужу и другие концепции тоже) .

Да, пожалуй)
Но ценность этой мысли невелика. Непростые решения невозможно использовать в промышленных масштабах
То есть, невозможно использовать "абсолют" вместо ООП или ФП для решения массы практических задач простыми смертными
Ограничения и несовершенство ООП и ФП не обнуляют их ценность

Ключевое отличие заключается, пожалуй, все-таки в referential transparency.

Niklaus Wirt про ООП:

Многие люди относятся к стилям и языкам программирования как к религиозным конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка. Объектно-ориентированное программирование вышло из принципов и понятий традиционного процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно нового понятия; просто по сравнению с процедурным оно делает значительно более сильный акцент на двух понятиях. Первое - это привязка процедуры к составной переменной, что и послужило оправданием для введения терминов "объект" и "метод". Средством для такой привязки является процедурная переменная (или поле записи - record field), доступная в языках программирования с середины 70-х гг. Второе понятие - это конструирование нового типа данных (названного "подкласс") путем расширения заданного типа ("суперкласс").

Стоит заметить, что вместе с ООП пришла совершенно новая терминология, имевшая целью затемнить происхождение его корней. Таким образом, если раньше вы могли инициировать активность процедуры путем ее вызова, то теперь должны посылать сообщение методу. Новый тип строится не расширением заданного, а определением подкласса, который наследует от суперкласса. Это вообще интересный феномен, когда многие люди узнают о таких важных (и древних!) понятиях, как тип данных, инкапсуляция и (возможно) скрытие информации, лишь когда начинают изучать объектно-ориентированное программирование. Что ж, одно это оправдывает излишний шум вокруг ООП, даже если позднее эти неофиты ничего этого и не используют.

Тем не менее, я склонен рассматривать ООП как аспект более общего понятия "программирования в большом" (programming in the large) - тот аспект, что логически следует за "программированием в малом" (programming in the small) и уже поэтому требует надлежащего знания процедурного программирования. Статическая модуляризация - это первый шаг навстречу ООП; этот аспект намного легче понять и освоить, чем полное ООП, к тому же в большинстве случаев этого достаточно для написания хороших программ. Вот почему очень жаль, что этим аспектам в большинстве языков пренебрегли (за исключением Ada).

Я бы не сказал, что распространившаяся практика ООП реализовала все свои потенции. Наша конечная цель - расширяемое программирование (extensible programming). Под этим я понимаю возможность конструирования таких иерархий модулей, когда каждый модуль добавляет новую функциональность в систему. Расширяемое программирование подразумевает, что добавление модуля возможно без необходимости вносить какие-либо изменения в существующие модули - не должно быть необходимости даже их перекомпилировать. Новые модули не только добавляют новые процедуры, но - что более важно - добавляют также новые (расширенные) типы данных. Мы продемонстрировали практичность и экономичность этого подхода при проектировании Oberon System.
https://www.osp.ru/os/1998/01/179366/

Про предметную область:
"Domain Modeling Made Functional" by by Scott Wlaschin
https://fsharpforfunandprofit.com/books/

Вот так сразу не процитирую, по-моему у Буча это есть.

Основным драйвером появления ООП явилась инкапсуляция,  потребность в "защите" состояния.

От себя добавлю. Сокрытие не имеет самостоятельной ценности. Важно иметь возможность контроля состояния. В процедурном программировании это без не костылей сделать.

Если апологеты ООП неофиты, то Вирт ретроград.

У Гради Буча в твиттере был несколько месяцев назад холивар на тему ООП. Дело в том, что у ООП была еще предыстория довольно длительная на тему ADT.

Не столь важно) В какой-то момент "нащупали" ценность - инкапсуляция

То есть, "болело" именно отсутствие контроля за состоянием