I view this as a breaking change in the behaviour of many internet servers, which happened to be motivated by security. Which is different from fixing the security of the software on the device.

Some other examples of non security issues that might require modifications:

* Widespread adoption hosting multiple services on the same IP, relying on SNI for TLS to function. While this is in TLS as well, it's not a security issue. In practice it was adopted slowly enough that it didn't cause many problems

* A quick switch from IPv4 to IPv6 (lol)

* Y2K (happened before smartphones)

* timezone database changes (e.g. if the EU abolishes DST)

* Regulatory changes (e.g. which frequencies the phone may send on)

* A third party service the phone relies on for essential functionality gets shut down

As a practical matter, it's a far cry from something like backporting a vulnerability patch. How likely is it that you can actually get TLS 1.(N+1) without a breaking change to an API?

It does, plainly. Just like not using MD5 is a security concern and patching that out would be a security patch.