Вопрос: В чем минусы событийно ориентированного подхода?

Лучший ответ:
Не претендую на правду. Просто несколько мыслей.

В чем минусы событийно ориентированного подхода?
Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.
Мысль первая. Наследие.

Когда мы говорим о наследии Алана Кея - надо просто глянуть что он создал практически.
А создал он язык Smalltalk. Поэтому логично изучать минусы событийного подхода на 
примере софта который написан с использованием Smalltalk. Кто из коллег в топике
знает примеры такого софта? Я - к сожалению не знаю. 

По ссылкам википедии https://en.wikipedia.org/wiki/Smalltalk можно видеть в категории 
influenced мы просто видим что Smalltalk
влиял на Java, Go, Swift. Но я здесь не согласен потому что мы не можем измерить глубину
этого влияния. Это все равно что сказать что Сталин влиял на Черчилля. Как влиял? На 10%?
Или более чем половину? Сложно. Насчет Java я тут сказал-бы что сомнительно. ООП? Может быть.
Акторы? Нет. В Java изначально нет акторов. Они существуют позже в виде фреймворков но
языком не поддерживаются.

По поводу MessageBus. Если брать технологию акторов которая используется в Erlang.
то там скорее не message bus а очереди сообщений между потоками-акторами.
Если про Smalltalk сказать нечего то про Erlang я могу сказать что на нем написаны
две единицы софта такие как RabbitMq (очень надежная и неубиваемая система MQ).
Может не супер-производительная. И CouchDb которая выделяется своей
устойчивостью ко всяким сетевым сбоям. Реклама говорит что Кауч работает
практически при мигающей сети, при обрывах и т.п. лучше чем аналогичый TCP-IP совт.

Мысль вторая. Что Кей говорил про ООП.

У меня есть цитатник. Я туда собираю некоторые слова на лытни. И иногда слова Кнута, Дейкстры
и прочих it-академиков. Вот из цитатника Кея:

I made up the term "object-oriented," and I can tell you 
I did not have C++ in mind.

Что в этой прямой речи можно понять. Что господин Кей открещивается от современного ООП.
А фактически все современное ООП зеркалит то что есть в С++. Здесь вы можете со мной спорить
о первенстве (я не буду спорить я не знаю). Но абсолютно очевиден факт что мир пошел по пути 
жесткой синхронщины в 80х. И пока все еще идет. Будут ли примитивные типы int/double обьектами
не суть важно. Тут важно что Кей постулирует среду в которой двигаются сообщения. Как сеть в миниатюре.
А классическое ООП С++ - лишает нас этой среды и заменяет ее вызовом метода. Никакого сообщения
в С++ нет и быть не может потому что сообщение НЕ существует в отрыве от основного потока который
инициировал вычисления. Умрет поток - развалится весь стек и параметры и все. В противоположность
в языке Erlang поток (процесс) приёмник может дохнуть много раз но стек сохраняет свою живучесть
просто повторяя вычисления заново. И здесь мне кажется и идет развилка путей. 

И здесь как-раз мы может говорить о недостатках. Очевидно что у нас появляется лаг приемки-передачи
сообщения. У нас появляются мягкие гарантии времени обработки. И многое другое.

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

Сегодня, когда мы нежемся в сладкой неге мощных процессоров и даже (!) облаков - мы можем
себе позволить любого уровня парадигмы и абстракции. Цена 1 абстракции стала настолько дешево
стоить что нам дешевле в банках запускать Java/Net приложения и на ходу фиксить ошибки
чем долго разрабатывать на С++ и иметь неопредленнное поведение и тяжелый анализ 
в случае падения.  Даже такой уродец как Python взлетел как язык интеграции а не разработки.

Мысль третья. Нестандартные и асинхронные архитектуры реализованные в железе.

Недавно смотрел анонс нового процессора от Чака Мура (это тот самый Мур который создал закон имени себя).
Мне кажется это пример той самой асинхронной клетки о которой мечтал Алан Кей. 

Мысль четвертая. На кого похож Алан Кей?

Не знаю как вам. :) А мне он уж очень напоминает Боливара Траска из Люди Икс Дни Минувшего будущего.

Мысль 5. Что делает Алан Кей на фото?

Бренчит на музыкальных инструментах. Наверное блюз. Блюз потерянных архитектур :)

Худший ответ:
Основной минус заключается в том, чтобы поменять мышление с активного на реактивное. Например, js работает асинхронно, что весьма непривычно для некоторых.

Дополнительный недостаток - это неэффективное использование ресурсов.

По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.
Не читал вашего Алана, возможно у него действительно подразумевается такой подход. Но в контексте событий не обязательно использовать общую шину или одну общую шину.

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