A great example I've been fighting with recently - a backend which requires a very large in-memory data graph which is unique for each user. Rebuilding this graph from the backing datastores takes between 5 and 10 seconds, but if it's in memory, responses take under 100ms.

The problem is that this monolith will be deployed in a microservice environment - stateless routers between dozens of docker hosts, each hosting multiple dozens of services, and any one of which can go up or down seemingly at whim.

Even if we were not concerned with the challenge of putting stateful applications in a stateless environment, we'd still have to worry through how to ensure that servers going down doesn't cause the entire cluster to rebalance and give everyone 10 second load times, how to route secure traffic so that users are always hitting the same servers (even across sessions), how to mitigate the data flood if the servers did catastrophically rebalance, and so forth.

So yes, theoretically, monoliths may be capable of scaling horizontally in a cookie cutter pattern. But the devil is still in the details.

Oh, and to fix your article/comments problem - just segregate off the one article to dedicated servers. Not too had a problem to solve, especially since newspaper articles are nicely routable via their URLs. Back when I worked with bare metal in colocated datacenters, it was a very popular method of handling popular customers.