I am so tired of these sorts of shallow analyses from people that think their screw-ups are actually caused by EDAs or micro services or whatever. They're even totally transparent about the fact that they did because they heard cool things but never say "so we sat down to learn about best practices, what the current state of the art is, and considered how our use cases matched the architecture"
They just say "we thought it would be cool so we just started doing it and it sucked - here's why that's an inherent problem of the architecture and not in any way related to our behavior".
Yes. If you take a team of people who build n-tier and hexagonal MVC monolithic apps, and then tell them to build micro services, they're going to build a bunch of n-tier or hexagonal MVC monolith candidates and eventually end up with a single service that does too much and ultimately becomes the monolith.
Yes. If you take a team that does 100% synchronous HTTP interfaces, SOAP or ReST, and then tell them to build microservices, they're going to daisy chain those microservices via synchronous HTTP interfaces, and if you tell them to build an EDA they are going to build an EDA that attempt to replicate all of the aspects of their synchronous HTTP interfaces with busy polling loops.
So stop doing that and actually do the hard thing of learning fundamentally different architecture, techniques, technologies, trade offs, best practices, operational patterns, design patterns, and heuristics and principles for managing software. Learning is difficult and humbling. But it sure beats writing ignorant articles like this.