Well, the stuff I'm seeing in this thread is all great, but I have a definition of an 'invariant' that has been tremendously helpful for me at work.
An invariant is any logical rule that must be obeyed throughout the execution of your program that can be communicated to a human, but not to your compiler.
This definition is helpful because it cleaves out conditions into two groups: those the compiler can be trusted with enforcing, and those that must be documented, discussed, commented, or otherwise communicated to contributors in order for them to interact with the codebase without introducing bugs.
Also, this definition is helpful because it allows you to use the generalization, "Invariants are bad".
As an example, the shifter in a manual transmission car is engineered to avoid an invariant. If I wanted, I could build a transmission with one lever for each gear. This lever could be forward ("engaged") or back ("disengaged"). In such a system, I have created an "invariant", which might be documented as such:
"It is critical that the currently engaged gear be disengaged before a different gear is engaged. To engage any two gears at the same time will cause mechanical stress that will tear the transmission apart. Always disengage the currently engaged gear before engaging another."
And so, one might blame broken transmissions on sloppy driving. Modern cars, however, use a single stick that pivots around among the gears. It's designed in such a way that, on a modern stick-shift car, it is not possible to engage two gears at the same time.
In this way, we could say that the transmission has been engineered to 'remove the invariant', because it does not permit itself to be mechanically configured in a way that violates the logical rule.
Every invariant of this kind that you remove from your code is an improvement, because it lowers the cognitive load of working with it.