The Laravel podcast folks mentioned a backlash about firing events in controllers, and I would guess those arguments were based on the notion that events can be used as a sneaky way of using global dependencies. Depending on the design of the event system, the party firing the event can access resources returned by event listeners, and this pattern can be abused like a service locator.

If you allow events to return resources and to be called within a component, you don’t really know a component’s real dependencies without reading the source code. Not at all does this imply you shouldn’t do it, but just that there are trade-offs anytime you reach out for undeclared dependencies at runtime.

What might give the best of both worlds is a way of injecting a dispatcher limited to a single event. E.g. make a class that triggers a particular event and depend on that. This would be best baked into the language similar to generics, so reflection could determine the event(s) needed without a bunch of boilerplate single-event objects.