To me it's a proportion of stability (as in cemented in concrete, clay baked in the oven, set in stone, written in permanent ink). The more unstable your code is, as in the higher the probability that you'll need to change it in the future, the more easily pliable it needs to be, like wet clay, to stay productive. I also emphasize pliability and not readability. To me the ease of changing code is more important than the ease of reading it. Code can be easy to read and a nightmare to change, and what use is being able to read and easily understand implementation details if they're a nightmare to change? Unless it's just an academic exercise, typically the point of being able to easily understand code in a production codebase is with the intent of being able to more easily change it as needed. If it's difficult to change, then a lot of the benefits of readability go out the window. Readability is only generally useful in the context of pliability, and pliability is only useful in the context of instability.
Naturally even the most difficult to maintain code imaginable, regardless of how easy or hard it is to read, doesn't pose a problem if there's never a reason to change it, only use it. And it is possible to achieve such a quality, especially for low-level system code where performance often tends to count the most. I have C code I still use regularly which hasn't changed since the late 80s. It hasn't needed to change since then. The code is fugly, written in the bit-fiddling days, and I barely understand it. Yet it's still applicable today, and I don't need to understand its implementation to get plenty of use out of it.
Thoroughly writing tests is one way to improve stability. Another is decoupling. If your code doesn't depend on anything else, then the only reason for it to change is if it, itself, needs to change. Sometimes a minor amount of code duplication can serve as a decoupling mechanism to dramatically improve stability in a way that makes it a worthy trade-off if, in exchange, you get code which is now completely independent of anything else. Now that code is invulnerable to changes to the outside world. Meanwhile code that depends on 10 different external libraries has 10 times the reason for it to change in the future.
Another helpful thing in practice is to separate your library from the unstable parts of your codebase, possibly even building it separately, as you might do for third party libraries (which likewise are meant to just be used, not changed, at least not by your team). Just that type of organization can prevent people from tampering with it.
Another is minimalism. The less your code tries to do, the more likely that it can do what it does well. Monolithic designs are almost permanently unstable, since the more and more functionality gets added to them, the more incomplete they seem.
Stability should be your primary goal whenever you aim to write code that's inevitably going to be difficult to change, like parallelized SIMD code which has been micro-tuned to death. You counteract the difficulty of maintaining the code by maximizing the likelihood that you won't have to change the code, and therefore won't have to maintain it in the future. That brings maintenance costs down to zero no matter how difficult the code is to maintain.