The architecture the author is describing is called SOA and to me is much more optimal. There's variations of SOA that can occur in a monolith or as separate services but at the end of the day it stresses separation at interfaces that most people like microservices for. Microservices are really only architecturally necessary if certain parts of your application have outlier performance characteristics where it wouldn't make sense to scale the whole thing for any number of reasons (eg: database connection pooling or some other metric).
As for why microservices got so popular I think the answer lies in writing. The more a pattern is written on the more likely it is to be repeated and modeled.
Finally, the author also goes in after cloud usage in general. We're a decade and a half away from the first of these convergences. I was a systems engineer in those days and I remember how terrible they were. Software engineers requested a virtual machine, a pool of network resources, firewall rules, etc and eventually they got what they needed. The primary motivator of the cloud wasn't scale per se, to me it was that now a competent developer has an API to request those things on. They're operating on machine time instead of human time.
Some people extrapolate the same argument above and replace cloud with virtual machine and containers, "Why do I need containers when I can simply operate this load balancer, some VMs on an autoscaling group, and a managed database?!" Again, we quickly forgot that for many software engineer immersing themselves in image pipelines, operating systems maintenance, and networking details bogs them down in releasing the thing they really care about - the thing that logically gets them paid. Containers, again, traded that complexity to another team that solves it once for many people and lets software engineers live a relatively less complex life from their perspective.
There's an old adage I used to hear in the Marines that goes something like, "If you're not in the infantry then you're serving it. If you aren't doing that then you should question exactly what it is that you do here." The same can be said for software and those outside of product - we end up living to serve those that are building more closely on the product itself.
That's how I contextualize this history/evolution anyway.