Объекты/классы. Хотя классы уже ближе к наследованию.

Классы могут быть без наследования, а наследование может быть без классов )
И Объект может быть без класса.
Ну то такое, эти концепты уже и так по другому называются.

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

David West вещает о том же примерно( youtube.com/watch?v=RdE-d_EhzmA&list=LLd6OFj5xQf9ZhwBb4EVbdSw&index=58& )

Но как только они увидели религиозно-чистый Smalltalk (где все есть объект и т.д.), то поняли, что это не для всех, слишком непривычно было всё это после понятного всем процедурного кода.

Да, и сам Кей в письмах писал что ST стал чем-то «Что нужно изучать». Так не только с ООП, так происходит с очень многими популярными идеями, они упрощаются до такой степени что ничем не отличаются от того что было до этого и натягиваются(название) на уже существующие решения.
Аля «Мы теперь Agile, поэтому будем делать больше митингов», а таски в спринт все-равно менеджер какой-нибудь накидывает единолично.

А вот если бы в Smalltalkе не было непривычных (да и ненужных) вещей, то возможно, что хотя бы Джаву задизайнили в правильном ООП, который был бы легок в использовании, безопасен и не вызывал бы ненужной когнитивной нагрузки.

Кроме как названиями некоторых штук(названиями а не функционалом), Java не особо чем на ST похожа. Это скорее «better c/c++» + крутая фича в виде кроссплатформеннсоти за счёт JVM (Ну девиз их там, типа «write once run everywhere»)

В общем получается, что Алан Кэй и «раскачал» ООП, и он же примешал к нему излишества, которые настолько отождествились со смыслом ООП, что оно в страхе свернуло не туда…

Там были проблемы с лицензированием, о котором syn и xerox не смогли договориться, из-за чего Sun начали пилить свой язык(Опять же — youtube.com/watch?v=RdE-d_EhzmA&list=LLd6OFj5xQf9ZhwBb4EVbdSw&index=58& ).

Претензия к ЯП может быть только если они делают использование get/set легче, чем полное инкапсулирование.

Мм… Проблема то не в языках. Я больше к тому что и на Java пишут процедурщину, и на всём.
get/set используют потому что на краткосрочной дистанции это проще и быстрее, а чтобы правильно инкапсулировать нужные данные и понять что с чем, собственно, инкапсулировать — думать нужно, а неправильная инкапсуляция/декомпозиция может оказаться совсем не лучше чем процедурный код.

И ещё

а) На уровне кода (программист): здесь, чем больше возможностей предоставляет ЯП, тем лучше.

Ну такое. Важно ещё сколько ограничений предоставляет и возможностей ограничений. Например отсутствие множественного наследования я вряд ли стал бы вписывать в исключении, потому что в каком-нибудь kotlin/C# столько удобных способов реюзать код, что наследование уже и еденичное нужно крайне редко.

Мы планируем митап по DDD в Москве провести. Приходите!
И мы ищем докладчиков (еще одного для этого митапа, и вообще для последующих). Давайте дружить и продвигать вместе!