That's not always true, especially if they use dynamic linking.

That is a fair caveat after a system upgrade, but I was thinking of a scenario where the compiler has been upgraded specifically.

argued that there was no business value to moving from PHP 5 to PHP 7

From the perspective of a manager who is looking only at the feature lists, what is gained by that change? The "after" feature list looks just like the "before" feature list.

I see his perspective and I have seen managers apparently make decisions with that kind of thought process. I have had to very carefully firewall Windows servers partially from the Internet, so their services were still available, but the wandering malware could not reach the SMB listener. There was no upgrade path because another piece of proprietary software relied on that specific version of Windows and the newer version would have required a large chain-reaction upgrade (including replacing some very expensive long-life-span equipment that was actually still supported by its manufacturer but not by the other vendor) to continue to support a small part of the business that brought in enough revenue to keep operating but not enough to justify that much expense.

The problem is what PHP did — breaking backwards compatibility and dropping maintenance on the older version. That Perl 5 remained maintained is why the Perl 6 fiasco did not kill all of Perl.

PHP was able to drag its userbase along because most of them barely understand what they are doing and have no real alternative to PHP. A few well-run projects happen to be in PHP because their early prototypes were made in PHP and incrementally grew complex enough that migration away from PHP is very difficult for them. As an example, last I checked, MediaWiki has an ongoing long-term effort to migrate to Python. The typical small PHP "app" does not have anything close to the level of developers available to MediaWiki. They are stuck with PHP, and the PHP runtime developers learned this after pushing PHP 5 on their community and have continued to abuse this power.

The perl developers do not have this power — mastering Perl in the first place requires developing a level of skill sufficient to easily branch out into other languages; I actually learned C after learning Perl. Perl developers can jump to other languages much more easily, and breaking backwards compatibility to the point of needing significant rewrites has a much lower threshold for those rewrites to go to some other language if there is the slightest hint that it could happen again. Put simply, Perl is a far better language than PHP, with a far more skilled community that, unlike most PHP developers, can already go elsewhere.

Accordingly, I argue that backwards compatibility must not be broken without very, very, very good reasons — and the advice in PBP does not meet that threshold for a language that famously touts TIMTOWTDI.