I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's often how they're implicitly sold as ideas.
That's undeniably true; but, it's too easy to slip from that to "good engineering doesn't require good architecture, good technology, etc." I think it has to be stressed that adapting the big picture features of a solution is as important as adapting the finer features.
On the other hand they are often sold as a way to increase developer velocity. And I do sometimes wonder if that is the case (based on personal experience).
People are selling it as easy. You can deploy them independently, each service is small with low complexity.
That it is not that easy in reality and that the total complexity increase is so big is not told as often. There is a team at my work with 6 developers developing something that processes a couple of gigs of data each day and has a front end serving maybe a hundred users total, I would guess 20 would be logged in at the same time.
Kubernetes, 10 microservices, 2 different types of databases.