You're exactly right, events by themselves are not bad, and can be very useful in large, modular codebases. But a bad implementation will only get worse over time, and the nature of it makes it nearly impossible to recover from beyond a certain point.
The problem is when the app is driven by events. When one event triggers another event, which triggers another, etc. One of the most extreme examples of this is WordPress, where in it's internals methods are rarely called on their own. They mostly call each other through events, which, while they can be augmented and overridden, means tools like static analyzers can't help, you don't have good stack traces, exception handling gets confusing. As a result, you really can't refactor that code anymore, since you can't really figure out who's all listening for the event anymore. But I've personally worked with many other examples in Android, JS, and PHP.
The alternative is to only use events as a reaction. Keep the logical path in normal function calls, send events as "notifications" instead, to broadcast what you just did or what you're about to do, without altering the execution flow.
Awesome point. Totally agree
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.