When should event-driven architecture be avoided?

No concurrency? No events. No more than a single team running a single service (even a monolith)? No events. Not dealing with asynchronous 3rd party APIs (eg: webhooks)? No events. Not dealing with arbitrarily many hosts/processes/tasks/objects communicating with each other, potentially asynchronously? No events. Not streaming? No events.

The customer couldn’t care less, so if you can deliver without all that complexity congrats!

That means you either have time to focus more on your customers, and therefore win more business, or you just take home more money if it is fixed-income contract work.

I consider companies that add complexity just because BigTechCo does more interested in playing or pretending to be on a path towards success than to actually be.

I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer clear of events, would be those where you don't care to have the benefit of decoupling.

As an example, imagine a small system where a user changes their email address. In the beginning you might only have one action "update database". As the system grows, maybe new teams start to add new features triggered from that event, say "send confirmation email", "calculate fraud score", "send new email to marketing vendor". You could just go and call all those APIs, but at some point you want to emit a "change email event" and just let the other systems do with it what they will.

When unrestricted, event driven systems don't have a well defined overall state or consistency.

Avoid if you have rules that depend on a system "state"

Having said that, toy systems aside, almost all systems require reasoning of their overall state at some point, so in general - avoid.

Event-driven models work great when you have problems that can be modeled as series or sets of reply/response events or cycles. It does not work great when your problem is stateful, when minimum latency is important, when your problem is essentially one reply/response cycle or naturally sequential. The internals of a 3d engine should probably not be event-driven (the api might be, however). A program for listing files in a directory should also probably not be event-driven. Nor a program for computing solutions to differential equations. A text editor definitely should be event-driven.

That said, IME, event-driven architectures are more often than not the right choice for complex software. It's just a very intuitive way to model software.

I tend to think of it the same way I think of moving to an eventually consistent database. You do it when you have to, and as little as possible.

You correctly identified the overhead of these approaches is massive and has implications bigger than the software. The impact on developers cannot be understated.

The approaches you listed are useful, and the dissent I have isn’t so much on the approach, as the timing of when it gets used. Tons of software will never need its benefits and shouldn’t pay the tax ever. Paying the tax before you have to is very rarely worth it in my experience.

It shouldn´t. The way to proceed is to overcome its drawbacks. The world is async, do not fight it.

When doing the necessary communication to solve PDEs numerically on multiple nodes.