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