I would argue that a parent component listening to events on its child is an unnecessary level of indirection. The parent creates the child (or at least it should, in my opinion). The parent should just give the child the callbacks it wants directly.

I've become more or less convinced that over-reliance on events is a big anti-pattern. Combined with mutable state, you get a lot of difficult to track changes in state. Some describe it as COMEFROM-based programming, the dual of the much-maligned GOTO paradigm. The COMEFROMs are your listeners and event triggers are labels they reference. The downfalls of each are pretty much the same: code that becomes increasingly difficult to reason about as it scales, because you have arbitrary global movement in control flow. COMEFROM is even worse because it introduces concurrency. Concurrency + shared mutable state is a recipe for subtle bugs.

So much of the time in a web app, an event only really has one listener. In these cases, a simple callback passed to the child component suffices. But even when you might need to have more than one component react to an event in a child component, I would argue that whatever is responsible for creating the child should still pass a single callback, which might simply be an entry point to dispatch logic on a controller whose only job is to mediate that behavior. Said controller might use or something else as its mechanism.

Why is it hard to reason about event based code? A framework will need the flexibility to enable any developer of any component to do what they need when something happens. That is what an event system enables.

If you want the events to be a directed tree, that's basically what angular 2 implements. Immutabilty is optional.

I can easily visualize a tree and reason about it. Gotos are very different. What you wrote seems like a bit of equivocation.

The parent creates the child (or at least it should, in my opinion). The parent should just give the child the callbacks it wants directly

That's what setting event listeners is. The parent knows about the interface of the child, not necessarily the other way around. So the child won't be able to know what callbacks to call. That is also why inversion-of-control leads to more stable platforms.