Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.

Some will do for sure - but it might not even be "most". There is a suprising amount of thread-per-request code out there. And actually it's doing fairly well - even at the scale of the companies you listed if you are using it in the right place. Right place here means don't use it for a frontend proxy which needs to manage 100k keepalive connections.

But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there.

A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.

This isn't actually a rebuttal of the point.

C/C++ are also used at Google, FB, Amazon, etc. It doesn't mean that it's not a problem.

I'd bet you're alienating well over half the entire field of software engineering with calling Java, C, and C++ "problems".

You're misinterpreting what I said. I talked about the "main problem with Java", and with C/C++. Saying that a tool has a problem doesn't mean it is useless, far from it.