Михаил Колобов

Да, ты прав, тут всегда серая зона и нету прям правильного или неправильного подхода
Поэтому стоит рассматривать это в контексте статьи. А рамках нее не хотелось писать свои шины событий и сервис локаторы
Только как этим пользоваться

1. Даже если надо будет использовать только один класс из UniRx, то я лучше закину его в проект, чем буду писать то же самое, но хуже/дольше. Тоже самое касается сроков/денег разработки. Закинуть UniRx - 3 секунды на перекомпиляцию. Писать свою шину событий такого же качества со всеми дополнительными возможностями UniRx - сходу не посчитать даже.
Также и с зенжектом. Даже если я буду использовать его как сервис локатор - лучше использую его чем напишу свой. Все те же время/деньги
2. В данном случае - не придется. И не вижу необходимости именно "допиливать", а не обвернуть например декоратором для дополнительного функционала. (например, пула сообщений, как самого очевидного улучшения)

Что касается архитектуры - я как раз про это же.
Моя статья не о том как в очередной раз написать шину событий. А о том как ее использовать)

Там написано «часть 1», еще успеем со всем поработать)
Да и с zenject работаем в статье. Опять же потому что не хочу писать велосипеды и никому не советую

В том числе и Observer, конечно
Но в своей сути любое увеличение числа промежуточных классов и разбивание зависимостей - это медиатор в первую очередь

3 плагина не для этого
Zenject это DI контейнер, он не связан с шиной событий
DoTween для процедурных анимаций
Но согласен, это не совсем очевидно из статьи
А в целом, не хочу учить людей писать велосипеды. Если есть устоявшиеся фреймворки, то лучше пользоваться ими.
Иначе с тем же успехом веб разработчик может выпустить статью «напишем свой реакт»

Хотя конечно интересно услышать про хоть одну новую «практику программирования из 2020-х или 2010-х»
Тогда прям сразу сяду за статью, как применить ее в геймдеве)

Лучше поздно, чем никогда)