That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes onto a webserver when it's needed, and not before.
PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished.
PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP developers have been tackling forever.
The mechanism isn't the point (and vhosts aren't really either). The point is what a developer (or ops) has to think about when deploying, and in this regard, the default PHP model has a lot in common with serverless.
I don't see a difference there, PHP code can run on any webserver your hoster operaters provided they route the request correctly (I've once used a web provider that would rsync your PHP code to a geolocated DC if they detected more traffic from your region). If this is via vhosts or other routing methods is almost irrelevant, PHP code behaves extremely similar to "serverless" code (except it's often much cheaper).