This would be a pretty major refactoring, if not a rewrite. The dispatcher pattern would allow us to instrument the bot better and build more functionality around it. For example, if we wanted to add some code which monitors for spammy ban lists to take some other action, that code could simply attach itself to the dispatcher and do its thing.

The instrumentation benefits include improved logging (we can just dump the dispatcher to the log) and faster, more reliable, tests. This test is an example of something which is already pretty close to using a dispatcher: it's relying on a signal from the event emitter to determine that an event was seen, but not redacted. If the protection in question simply did a dispatcher.send("nsfw", eventId, {actioned: false}), then the test could watch for that instead (and the runtime application logs would be clear that the event ID wasn't being processed for whatever reason).

A danger is everything connected to the dispatcher needs to be fast because while NodeJS can do async code, it's still a single thread. Element Web/Desktop has an internal dispatcher and occasionally spammy dispatches can slow down the whole application because it "wakes" every single listener.

Using a central event emitter as an event bus instead of a dispatcher could work to scope the dispatches to things that care, but can create a star-like call pattern instead of a bus pattern, which may be harder to debug/log when issues come up.