As Deborah alluded to, I think the key is the whether the deployment cycle is long or short.  For many consumer devices these days (e.g., phones, embedded systems), there are enough layers between tz and the end user that short-notice changes like this simply won't make it to them in time.  In that case, it's better to assume something slightly incorrect than to assume no changes, since the end user may not be able to update the data themselves, or may otherwise be resigned to employ kludgy workarounds.  If the end user doesn't have a say in the matter, to simplify their lives, it's better to have them experience mostly correct data than knowingly false data.

This is in contrast to people administering more complex systems (e.g., servers, networks), who should presumably know enough about what they're doing to be able to proactively (or at least reactively) seek solutions.

Obviously, it is a goal of the tzdist working group to reduce this number of layers and/or the time it takes changes to propagate through them, perhaps to a point where not assuming changes long-term becomes the more reasonable option.

I don't think we're there yet, though, so I approve of Paul's conclusion.