I think the main confusion is the callback thing as you can feed a function to get the returned result or emit an event and using another function somewhere else to receive that result. Javascript was designed for browser (GUI) which means its main job was to handle users' actions. So the event system was invented to decouple the "triggers" from the "actions". You can implement the exactly same paradigm in any other languages (actually a lot of GUI SDKs have equivalent facility). And if treat the callback as the return in other languages then everything would be clear.
The conclusion is
1. Throw an exception (which will stop the programm) if it's a programming error.
2. Handle it in place using callback just like you return the error code in other language if that's an operational error (e.g. user didn't input password when login). Emit an error event is really a special case of the callback when you want to handle error somewhere else (maybe globally).
So I think the article is more about when to "throw an exception" vs "return the error" if you take out those javascript special juices.
I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.
Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).
https://github.com/lsm/alfa/blob/master/docs/alfa.gif