Hey WP folks, I think there are a lot of important circumstances overlooked here when it comes to the talk of the wb hosts. I work at a small managed web host, catering to hundreds of non-profits and charities. I find the part at the end about forcing the web hosts to comply to be quite alarming! ... as it's not actually their fault or something they can fix most of the time!

On the host side of the euqation, we have all moved on to PHP 7 long ago (2 Debian versions ago for us). Yet the majority of our older WP customers are stuck on PHP 5.6 because they haven't the budget or the slightest understanding of what's involved for a successful upgrade.

The PHP upgrade notice dialog is totally unhelpful as it mischaracterizes the problem as a security issue (unless someone is compiling old PHP from upstream source, it's not, PHP is running with backported fixes from a distro security team and is arguably more secure than when it ships from php.net in the first place).

Anyway, about 90% of the time when a customer contacts us about the message and we go through the correct safe proces to update (see below) we discover that their site would have been broken if we had just changed the PHP version!

So here's the actual problem, what commonly breaks when you upgrade PHP 5.6 to PHP 7.1+ on a wordpress site is all the expensive stuff:

Premium plugins that were purchased years ago and never updated regularly, these do not support PHP 7 coding standards and break horribly. This is hugely common.
Solution: is to pay for each of these again and upgrade them ($ for plugins and $ for developer time to do the work, plus some kind of dev/stage environment if the developer can't provide that themeslves)
Problem: info on the correct solution, the cost, and competant dev help are a barrier to entry
Custom code in theme or chld theme. Those snippets that finally worked that the old developer copied into functions.php from some stackoverflow answer 5 years ago? The code the part time student thrashed together that one summer for cheap? That code the marketing person made work that the support people gave them? These are the types of things that will be broken in PHP 7. They may spew warnings, or worst case cause fatal errors and dead pages, or prevent the site loading altogether.

Solution: Debug the problem starting at the error_log entries and working back.

Problem: barrier to entry finding developer: debugging old code is harder than writing new code, the work is beyond horrible and no one who isn't desperate will touch it with a 99 foot pole, due to its complexity the work needs a more senior developer willing to do that awful work, these people are hard to find and expensive.

Custom plugins. This indicates more serious development skills when first built, but when it comes to debugging problems that's usually a curse and not a blessing. Now the problem of the above point is abstracted and confusing to reverse engineer, plus it likely relies on ancient / obselete / insecure frameworks or libraries that also need to be upgraded to modern versions in order to fix them (which then triggers a chain reaction of destruction throghout the rest of the dependencies). It can be cheaper to rewrite than to fix these, at the cost of a bunch of functionality. A painful sacrifice for the customer to make. Again, that is if someone is supporting them hand holds them through all this... otherwise they just ask their host to update PHP and often that's a one way change they can't undo and their site is wrecked, game over.

Depending on the size of the site, and taking into account the work involved to successfully test and fix in an offline instance of the site, an organization can often be looking at thousands of dollars even if things go well.

So! Let's please not all get our burning torches and march down to the web hosts front door just yet... this isn't their falut and it's not their problem. Most of them could activate PHP 7 everywhere at the flip of a switch. They are more aware than most people about internet security and so they would love to be able to do so if it didn't almost always completely destroy their customers sites (and thereby livelyhoods). So ironically except for bad ones (below) it's the ones that give a crap about their customers who aren't doing so automatically in a lot of cases. Forcing it on the users is the easy solution for the hosts but the results for users would be disastrous!

And yes it's true there is a lot of bad infra out there that is dangerously out of date and EOL, where it is the host that is the blocker! But often the host is not selling upgrades or support in those cases and it's $5 hosting... Even more common than that is where someone back in the day had the bright idea to admin their own VPS without being a provessional (I wonder if they fix their own car and do their own plumbing and electrical too? things that make you go hmmmm!!??). This can be fixed or migrated away from but is more specialty help, then all the above points still apply.

Anyway, what the wordpress developer community should be doing IMO is addressing this issue by educating users and connecting them up with developers (who must help with their part of the problem by fixing other random developres stinky obselete code). The end result of which, for our selfless heroes, will be a new ongoing wordpress maintenance & dev client..... because you are going to explain about maintenance and security updates to them and not let them get co-opted into a giant botnet right? :-)

sincerely,
a caring webhost who wants to get rid of PHP 5.6 even more than you!