[kls]

For instance, many event systems “call” a method in another module by sending an event and expect a “return” from that method via a similar event mechanism. In order to understand the application, the programmer must mentally match these call/return pairs, even when they are in different parts of the code.

I somewhat disagree with this assessment. Just as there are different threading models, there are different event models. What the article describes is a pub/sub model of which I am not a big fan. I prefer an event observer model where an event as a very defined namespace and method signature or interface. Observers must conform to that interface to observe the event, therefore to find code relate to that event one only need look up what implements the events interface. I find that the way event based systems deal with control flow reduces a great deal of control flow programming which is where a lot of spaghetti gets implemented. Choosing the proper event model is just as important as choosing the correct threading model.