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.)