Right, and they are, that's my point. Quality isn't a single attribute of a system, it's a judgement call based on objectives.
The objectives of a business selling software, and that of engineers is something else. Sometimes maintenance, sometimes extensibility, sometimes exploration, sometimes just seeing if something is possible. Quality correlates to the objective, and in my experience, many software engineers have a hard time seeing their code through other perspectives.
There is a lot to be said for getting outside the four walls of a business (or org) to evaluate things. If it's not visible outside those walls (software buggy enough to lose customers) and doesn't introduce significant future risk to the business (competition can move faster than you) it's probably good enough. The real trick of course is predicting and communicating why you think one of these is true. It's an essential problem of commercial software dev.
The objectives of a business selling software, and that of engineers is something else. Sometimes maintenance, sometimes extensibility, sometimes exploration, sometimes just seeing if something is possible. Quality correlates to the objective, and in my experience, many software engineers have a hard time seeing their code through other perspectives.