Some folks will never come to it, some folks will stick with it (like me).
Language is language. The value prop for most orgs using tech is the ecosystem. The PHP ecosystem is large, and has a lot of good quality stuff available. Building on laravel or symfony, or using products and services built around those, can be a big advantage over some other tech.
There are always examples and counter-examples, and usually a decision will come down to "you should use what a team is already skilled in". That's the pragmatic answer. You have a team of .net folks... don't jump to express or flask or laravel because of some benchmark or neat article or resume-driven-development. Stay in the .net world, and use what you know. That has to be balanced with "what you know may go away, so be ready to learn new things". Maintaining a balance, both for yourself, as well as the tech in your organizations, is something to regularly be aware of.
I love PHP. I like web stuff overall. Over the last... 30 years of software dev, what I've noticed is that the really useful/good ideas tend to get implemented in various languages if they're useful. The sign of a useful library can often be that there's multiple implementations of it. We saw a productized "web mvc" launch rails, and we then saw a dozen variations in other languages take the essential parts, implement them, and good ideas have flown between various tech camps for years since.
There are counterpoints to that. A colleague is doing some work in SciPy, and there doesn't seem to be an equivalent outside python. In PHP, we have FlySystem, and I've not yet seen an equivalent outside PHP. I've seen some attempts, but they tend to have one or two adapters, and that's it.
Overall, language diffs are often/mostly personal preferences. Your project or business isn't failing because your language of choice can't connect to a database quickly enough, or that you can't write data to filesystem, or whatever. But if you've spent X years with tech Y, you will likely be faster than learning something new (and learning the idiomatic methods of that new tech). Figuring out when to dig deeper, and when to move on... again - no single choice on that.
I may have shared it before, but I saw a company moving new dev away from PHP, and moved to a combination of python and node. "It's so much easier to hire people!" But... they were largely hiring jr and mid level people, and they were doing greenfield redevelopment of some of the PHP stuff. And... they'd attempted a rebuild of the PHP stuff once, but made the same mistake as the first time; primarily one person, working on their own, often offsite, not interacting with other people.
Moving to python/node, they hired more/cheaper people, and the rewriting team required everyone to work together. The languages were pointed to as the reason behind some of the early success, but it was far more the processes around the development that provided the success. With enough people, forced to write cleaner code the whole group can understand, as well as requiring tests and documentation... yes, the outcome is going to be better than requiring one person to build a lot of stuff on their own, without providing adequate time for testing, documentation, or collaboration with others.
Likely most of us have come across enough bad JS/Python/Perl/PHP/Java/C#/etc to understand the quality of the code is only tangentially related to the language, and far more about the processes and expectations set around the development.