Using PHP in 2022+ should be considered a crime of negligence.
PHP today is so so SO much better then the blubbering eldritch horror that was php 4/5.
I'm still not going to use it until they fix the ad-hoc/chaotic naming of their built in functions, but it seems there's a proposal to alias all their functions to new names that make sense and are consistent with each other. When that happens php will not just be widely productive, it'll be widely liked too.
What should those negligent people use instead, particularly?
What's your suggestion for an alternative system that is as deployable?
I understand that it is convenient to deploy, but a single exploited vulnerability can turn a web server into a part of botnet, forever. And this has happened, numerous times.
I don't have a specific suggestion for alternate system, but it should have a very clean separation between "code" and "data", and have a very easy way to completely replace "code" part. This can be done with Docker, or deb-style installation, or just a sane design which keeps things separately.
And of course you can do it with modern PHP.. it's just that language makes it so easy to do the insecure thing. "I'll just make an uploads/ right next to my index.php, so users don't have to mess with server config too much" - and bam, you have a vuln. Compare it with Golang, or Java -- you'd have to work real hard to make this kind of vulnerability there.
Aside from WP installs I definitely lock down PHP execution to the single entry point; it's possible to do it with WP too, there are just a few more entry points, alas.
So if starting a new project, you either have a choice of going with PHP and trying to re-educate many experienced PHP programmers that their best practices are insecure... or maybe choosing some other language, like Golang and Python, instead. Those languages are secure by default, there is no need to force people to go against the grain.
I've implicitly mentioned "ease of deployment" myself in this thread, I think, and probably in others, and I don't care for the assertion. I suggest you ask the others who have, what they mean.
"Secure by default" is a big claim. Secure against this particular problem you identify, sure. But let's not over-egg the pudding; there are still vulnerabilities in popular Python frameworks.