I worked for 27 years, for a company (Japanese) that is over 100 years old. It is world-renowned, and one of the top brands in the world; a synonym for "Quality." I won't name it, because I don't want them to have to deal with my random stuff (although I won't say bad things about them). It's easy to figure out, if you care enough to look at my profile. Although I often had fierce disagreements with their management…
There are massive economic benefits to shipping something early but a little buggy or even incomplete. Does it take some of the artistry out of being a programmer? Sure! In fact the ability to compromise on quality, to tolerate a little technical debt, is a sign of maturity I look for when interviewing senior engineers. In software it's possible to waste months and months of engineering time endlessly iterating on the implementation in the name of "quality" while realizing minimal value to the business. For example, obsessively aiming for 100% test coverage, rewriting working code in accordance with a new fad style or framework, adding a new abstraction layer where it isn't required, etc. An engineer who refuses to fix a minor bug in a "crufty" part of the codebase without spending a month rewriting it from scratch is not the kind of engineer I want on my team -- it usually goes hand in hand with a lot of nitpicking on pull requests, overambitious designs, derailing of technical discussions. In other words, ego.
It's not that I don't care about quality. It's just that I've worked with lots of people who equate quality with their own tastes, and they can be really unpleasant to work with.
(Note: none of this is meant as a criticism of you, OP, more a general rant about the flip-side of "quality" in software engineering.)