It's not that bad anymore. We do have fcgi, fpm, and also user space caches like apcu. You would have to try pretty hard to find a default set up that resulted in process per request these days.
It scales very well on a single host. Which has limits, but limits that exceed some percentile that most projects need. And things like redis take it even further. If you're pushing the limits of php, you probably have a nice-to-have problem tied to lots of incoming revenue. Similar to FB and HHVM.
I agree there's a scaling issue, but nobody is doing process per request anymore. Process pooling is a decade old or more.
I guess the objection to "spinning up a process" is actually a problem with slow PHP initialisation, though? A dinky server can spin up many thousands of processes a second. I'm pretty sure OS process overhead is nothing compared to whatever PHP or Rails or whatever else puts into your critical path, but the language/library/parsing requirements could kill you. (Though people still make this objection to CGI itself, not just PHP...)
Buzzword bingo and all...