It is hard to imagine any reason as to why a normal site/blog couldn't cope with this.
Now since whatever solution you pick is going to be an overengineered mess it's easy to understand each in isolation, most of us don't have the time/energy to optimize for this. And that is fine!
But it is kinda sad that the quick and easy approach is not a statically generated site. There is absolutely no reason why that should be any harder.
Yet for some reason we don't value that.
And we do value it when downtime loses us business, something that's not likely to apply to our personal blogs.
Maybe Wordpress should enable some low-risk caching by default, but maybe it's not worth it since most installs never get traffic and caching is confusing especially to the non-tech-savvy.
This type of architecture is really only suitable for a narrow problem domain, imho. Most people that I've seen attempt it don't understand all of the edge cases that arise from it.
For example, not getting immediate success or failure status from an API call, and having to constantly poll to see what the status of a submitted message is.
For example, an asynchronous API should have a way of pushing notifications to the caller, and the caller then has a way of processing these returns.
Moral of the story is there's a lot of information being preached by those who either haven't or won't put that knowledge into practice first. It would have been nice to hear about any projects the author could point to and explain how the architecture helped it succeed, but that is absent from this post.
Nothing is inherently bad, unless you use it for the wrong purpose.
"Error establishing a database connection"