Is a monolith bad architecture?

The statement is false as stated. A monolith is one deployable; it says nothing about the boundaries inside it. Its advantages are real: one build, one deploy, local development that runs the whole product, in-process calls that cannot time out, and database transactions that span the whole domain. Most distributed-systems problems simply do not exist.

A monolith scales horizontally the same way services do: keep it stateless, run N copies behind a load balancer, put sessions in Redis. What does not scale that way is the database, and that ceiling is the same whether the app tier is one process or twenty. The honest disadvantages are elsewhere: a large codebase where boundaries erode, coupled deploys when many teams share one release, and inefficient scaling when one module needs far more CPU than the rest and drags every copy with it.

So the question is not monolith or not, but whether its internal boundaries are enforced and whether the team has hit one of those specific limits.