Dropping half a sentence will often make it sound goofy, yes.
The point being made is "you don't need a massive K8s infrastructure to handle hundreds of thousands of orders a month". Most people don't; https://www.joelonsoftware.com/2001/04/21/dont-let-architect... is an oldie but a goodie on the subject.
This is true of many languages that are slower and faster than PHP. It's not useful as evidence of PHP being a better choice for anyone.
It's an argument that raw language performance in this sort of context isn't going to be the problem for 99.9% of people developing code. If you have 500k orders a month, you can afford more than $6/month in hosting.
I sometimes see folks post on StackOverflow trying to micro-optimize things like string concatenation or single versus double quotes that make perhaps a second of CPU difference in a million executions. The point is directed at those folks; the ones who are thinking "language X is faster, and for that reason alone I should use that instead".
On top of that, You don't need massive k8s infra for any other framework either, so it isn't really a selling point for PHP itself.
So with hardware specs better than the Chinese laptop I bought second-hand for 150 EUR (which has a Celeron J CPU), the very same one that can serve 2000 req/s on Elixir and 5000 req/s with Rust, then?
Sure, waiting on the DB is often 95% or more of the request, I get it, but 0.2 requests per second (which is the 500K orders per month when you do the math) is nothing to brag about regardless of which language or DB are being used.
It's even below the level of having a bash script doing the heavy lifting.
Also the numbers are still irrelevant for the server because if you do 500k orders a month you owe it to the users to respond faster than 1s and also be highly available (just take 3 servers somewhere idc about anything else)