How is that any different for an API-driven architecture? You'd need to track down all consumers of your API you're wanting to make a breaking change to.

I really dislike this argument, because it puts the duty of managing dependencies and requirements directly on code. This is organizational issue!

First, if your event (or whatever) changes enough that there are inter-component breakages it means engineering requirements must have changed and tracing dependencies of requirements is organizational thing.

Second, you either do trunk based development and constantly break downstream or do leaf based development and have constantly out of date core dependencies. In any case, that's release version management, which is again organizational thing.