It's in the JEP (https://openjdk.org/jeps/523):

> We made G1 the default collector for server environments in JDK 9 (JEP 248). At that time, testing showed that Serial had significant advantages in throughput and footprint in constrained environments with a single CPU or less than 1792 MB of physical memory. We therefore adjusted the JVM's GC selection algorithm to choose Serial in such environments.

There are edge cases where GC issues can crop up, in particular specific "serverless" models (eg AWS lambdas) where the JVM can get "paused" between executions and GC doesn't cleanly run, causing memory to trend upwards until the next cold-start happens (especially if you're running it within a docker container yourself). Limited CPU situations that can exist in these kinds of runtime environments also limit GC in several ways, too.

It's selection bias. There's a huge number of GC language users, but those who experience problems tend to be the ones who comment.

You're right; the vast majority of people use GC just fine and go about their day. We should update little to none when we see evidence of GC hardship.