The universe of developers with PHP projects to maintain is filled with people who do not share the same goals and constraints that you might enjoy.
There is an enormous amount of lousy PHP code, and more being made by clueless developers. But please do not dismiss the need to support old PHPs as being driven primarily by those reasons.
1. The PHP project itself has EOLed 5.3.3, however distros continue to support it with backported security and bug patches of their own.
2. PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on.
3. About 50% of sites running PHP are at versions less than 5.5:
https://w3techs.com/technologies/details/pl-php/5/all
https://w3techs.com/technologies/details/pl-php/all/all
4. Updating PHP is not like simply updating my Web browser. Real-world production hosts like mine are filled with various work by various developers over years. Bumping PHP further than a maintenance release would almost certainly mean unnecessarily breaking things that are hard to find, probably tricky to fix and written by people I’ve never met who are long gone.
It sounds like you are talking about providing hosting for older versions of PHP code. Which I of course understand is a necessary thing. You can't force people to upgrade their codebase. They'll just find another host.
But they'll finally listen to engineering... any year now...
"PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on."
https://news.ycombinator.com/item?id=16161455
The point isn't that you can't or shouldn't do it, but that it is much more trouble than you might think for many people. There are implications that apply to others that you might not see or care about for your particular situation.
The Node team has done a great job here, they have a number of ways of doing managed source installs that avoid a lot of the ugly hassles you can usually hit. Ruby has rvm which also handles this quite well. This helps work around any friction you might get at the distribution level.
If PHP is being held back by distribution maintainers then that's a problem that the PHP community should fix. 5.3 came out in 2009, it's ancient.
Look, one-line register_globals polyfill.
Sometimes it's for lack of knowledge (PEAR? Composer? What's that?) but all too frequently it's outright hostility to the very idea, like if it isn't PHP core it's not even worth considering.
`password_hash` and `password_verify` have been around for ages now and if your PHP is old enough that it doesn't support it, that PHP version is no longer actively supported and is probably riddled with unpatched security holes, so good luck with that!
There are some great, new cryptographic functions that have been implemented in PHP >= 5.5
Password_hash() and password_verify() are so simple, it's hard to mess up password hashing now. When I upgraded my projects to PHPa7, I replaced dozens of lines of code with those 2 functions alone.
But I have seen plenty of implementations of them that still fall back to old more convoluted and error prone methods when you are using some old version of PHP.