That's non-negotiable to me. You can make a short-term decision e.g. this implementation will only scale for the next month, but automated testing, clean code, other standards must be maintained.
I think I have to agree. I understand the impulse to say that it's implicit, and certainly the desire to build a quality product usually is. But in reality, to actually verify quality before you ship often requires a lot of costly infrastructure and time-consuming work. So in practice, it really is a lever that often gets sacrificed---usually at the alter of the timeline. You could argue that a feature that is broken isn't a feature, but there are many subtle degrees of broken-ness. A bug that happens 1 in 1000 times might be acceptable, or it might not.
...if you consider quality a lever, you're not the kind of person anyone should want to work with!
You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!
You could just as easily say that you agree on the feature set beforehand, and you deliver that feature set, not more, not less (you deliver sooner if you finish the features early).
"The quality level you agreed beforehand" is meaningless without some infrastructure and processes in place to verify it. And in practice, those infrastructure and processes are compromised at least as often as the feature set, the budget, or the timeline.
Quality is implied within the feature/scope grouping. Its always a three leg stool trade off for balance. Changing your quality output is just reducing or adding to scope requirements.
Budget = Resuorces / Time = Time / Scope = Quality
Quality could be grouped with features as "usefulness" of the software. Low quality software is unusable, or more expensive to use.
Timeliness has an equally direct impact on software value, but in this planning context it makes sense to distinguish what is delivered and when it is delivered.
You forgot about quality. It can blow the other 3 out of the water.