The Rule Is Not the Invariant
Every rolling-release Linux distro has the same piece of folklore: never update just one package. Sync the whole system together or you will eventually end up with a binary that wants a libc newer than what's on disk, and a half-broken machine to show for it. It's good advice. It's also not the actual rule. The actual rule is narrower, and the folklore just doesn't bother stating it.
The real invariant is: the versions of everything a given piece of software links against, reads config from, or calls over a socket have to match what that software was built assuming. "Sync everything together" is one cheap way to guarantee that. It's not the only way, and it's not even the most common way the invariant actually gets satisfied in practice. A statically linked binary with no shared library dependencies can get updated on its own all day and nothing downstream cares, because there is no downstream. A system package that other packages dynamically link against is a different animal entirely; bump that one alone and you've changed the floor everyone else is standing on without telling them.
This is the general shape of almost every blanket operational rule I can think of. "Always deploy the whole stack together." "Never touch config in isolation from code." "Run migrations only during the full release window." Each one is doing the same move: substituting a rule anyone can follow mechanically for an invariant that actually requires you to know something about the system's internal coupling. The rule is a compression. It throws away the information about which dependencies are tight and which are loose, because stating that information requires understanding the system, and the rule was written for people who are, reasonably, not going to take the time.
That substitution is a feature, not a bug, for the audience it's aimed at. If you don't know which libraries are ABI-stable and which aren't, which services actually read the shared config versus cache a copy at boot, which clients are pinned to a version string and which negotiate, then "just do it all together" is the correct answer, because any answer that requires that knowledge and you don't have it is a coin flip dressed up as a decision. The rule is a floor. It's there so that not knowing doesn't cost you a broken system.
But once you do know the underlying coupling, the rule stops being a safety net and starts being a tax. Knowing the real invariant tells you something the rule can't: exactly which deviations are free and which ones are the ones that put you in emergency-mode recovery. A userspace app with no shared-library entanglement, pinned against a server that's enforcing a minimum client version, is a textbook case for updating ahead of everything else, because the invariant it depends on (client/server protocol version) is already satisfied and nothing else changes. A core system library that half your installed packages dynamically link against is the opposite case; the rule and the invariant agree there, loudly.
The failure mode isn't breaking the rule. It's breaking the rule while still only holding the rule's-eye view of the system, mistaking "this looks standalone" for "I've actually traced what this links against." People get burned not because they deviated from the blanket policy, but because they deviated on vibes, treating their guess about independence as if it were the same thing as having checked. The rule, followed blindly, at least fails safe. A guess dressed up as understanding of the invariant fails exactly when you least expect it, which is the whole reason the rule got written as a blanket statement in the first place: because most people's guesses about coupling are wrong often enough that removing the choice beats trusting the guess.
So the useful question is never "is it okay to break the rule." It's "what is the rule actually standing in for, here." Once you can name that, the rule either dissolves into a case-by-case judgment you can make with confidence, or it reasserts itself exactly as strict as it was, because the coupling really is that tight. Either way you've learned something the rule itself was never built to tell you.