Not the person you're responding to, but I was on a team which probably did the same thing.

Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that.

A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer.

Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.

By indirectly I mean that we have a WebSocket API that does nothing more than expose the primitive streams.

Our frontend client basically reads any stream it needs. And the main problem is, if you have to handle 40+ streams (and that is not even 30% of what's to come), it gets more and more difficult to provide a good user experience.

Thankfully, after much discussion we agreed to do it better... Soon ish.