Not that I think stateless is inherently superior, just that containerizing and scaling out sort of assumes moving state out of the application server and into redis, postgres, mongo, elastic, kafka, rabbitmq, …
As the OP points out, GC in java-land isn't worth writing home about on 1vCPU. When you throw a 16GiB heap at it though, with 16vCPUs then you'll unlock some of the really interesting optimizations and garbage collectors that the showcase the JVM in an advantageous light.
So it's not that the JVM can't scale horizontally - that's a matter of system architecture - it's that scaling it as 100 tiny nodes is far less impactful than having 5 large nodes.
The problem is using JVM without understanding some basic properties of it. Scaling is a matter of how you programmed it, not the language used.
Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves the performance problem with dozens, sometimes hundreds of replicas for one particular microservice. Many developers don't even understand the impact the JVM has when running on a single core (yeap... you get Stop the World GC - aka Serial GC - by default).
And then, the dev team decides to move to a new language because of performance and cost issues. And that by itself just brings many other problems.
All they had to do was keep the same amount of CPU and memory, but less VMs and replicas, with more vertical resources. Depending on the workloads and the system, it is even possible to reduce the cost.
All this is caused by the push in the industry for companies to go Cloud Native.