I do agree with you, there is already a group of people that solved that problem, and eventstorming is nothing totally new. (nothing ever is tbh, all renditions of other tools). Looking at the history, it comes from Domain-driven design where we try (quoting Mathias) to put lot of emphasis on shared models between business, devs, testers, documentation writers, UX.
The problem I mostly see is that each of this body of knowledge has their modelling tool, one where you need to have some form of workshop or certification (UML, Archimate, BPM etc etc..). What EventStorming tries to do is minimise these handover from proxy domain expert to avoid cognitive bias made from telephone games. So it tries in a simple and quick way to share knowledge in a multidisciplinary group and create a shared mental model, and do this continuous. It tries to show ambiguity in the language (something DDD looks for to create bounded contexts).
About the facilitation, you are totally right. A good facilitator is what makes or breaks it. Besides EventStorming is not a silver bullet, it has its flaws and its blind spots. So then you need your facilitator to grab out their toolbox and see how to battle this
Interesting point about trying to minimize the proxy expert game. I myself don't have full clarity on which level of proxy is OK. Should it be a dedicated person (typically an analyst)? Should it be the team? Part of the team? Someone mixing roles e.g. dev who talks to the client(s), or PM who also manages the backlog, etc.
There are many tradeoffs to consider here. If technical team has to talk to clients, well, we will lose some clients, period. Many types of clients and many types of engagements (for a software house) are simply unavailable, because we will lose out in competition with companies who will be given very good support by great client-facing specialists who will woo them, and actually give high quality consulting and value on the early stage of the project.
However, if we put those good business guys in front of the team (or as part of it), they start to lead the process, and our less developers who are usually much less ready to talk to clients etc. and have tech-related biases, suddently lose the best chance to learn. Because when someone takes away the difficult part of managing the client and trying to figure out what they need, you stop thinking about it on your own and you don't develop those mental models as fast (if at all).
There is maybe a middle ground where there's a mix of comms coming from technical and non-technical folks, who knows. In my experience this typically morphs into either model though.
The problem I mostly see is that each of this body of knowledge has their modelling tool, one where you need to have some form of workshop or certification (UML, Archimate, BPM etc etc..). What EventStorming tries to do is minimise these handover from proxy domain expert to avoid cognitive bias made from telephone games. So it tries in a simple and quick way to share knowledge in a multidisciplinary group and create a shared mental model, and do this continuous. It tries to show ambiguity in the language (something DDD looks for to create bounded contexts).
About the facilitation, you are totally right. A good facilitator is what makes or breaks it. Besides EventStorming is not a silver bullet, it has its flaws and its blind spots. So then you need your facilitator to grab out their toolbox and see how to battle this