Re: fairly sensible explanation ...
>It's nonsense. The argument is "that's broken and exploitable, so leave it like that until both things are fixed."
Ok, so hypothetically, the person who is upgrading discovers, upon upgrading , that their stuff no longer works in some way.
a) go, oh well, must have been insecure, lets try and fix forward while everything is down.
b) Roll back the upgrade immediately (and delay updates to production if they discovered this in test).
99.999% of people will do b).
Thus not only that one bug that was "fixed" will still be present, so will loads of other bugs that the upgrade would have fixed. If you are very unlucky, the impact of the failed upgrade will include some kind of risk exception so that the software is not updated again (at least until the failed upgrade is investigated, the root cause discovered and the upgrade retested/rescheduled).
Making security fixes not break everything is pretty important, because if they do, people will not install them in a timely fashion