Agree with the comments. Quality is a spectrum, and it's actually one of many levers we can pull out in the industry to achieve different goals. For example, sometimes (hopefully rarely) you must deliver something by a specific date, hard stop. You've got a few options: you can de-scope the deliverable, you can increase resources (which usually means hours and not bodies... we all know throwing more people at software usually does not help), or you can decrease quality. Now, that's a last resort level for me, typically speaking, but it is a lever I use. And yes, often that results in technical debt that we then need to take the time to address after the "date" in question. But does that mean I shouldn't do it?
Professionals should be cognizant of the serious negative consequences that may result from poor quality and should resist any inducements to neglect this responsibility.
To Kurt's point, not all software needs the same degree of quality. And I would also argue that within even one software product, different parts require different amounts of quality. For example, in the product I manage, we deal with financials of creative professionals, and we also deal with posting creative content, responding to it, etc. The financial portion of the product absolutely must be high quality, and, more importantly, accurate. While I would love to have the entire product at the same high level of quality, that's just not the reality of being in a startup.
How about this:
Computing professionals should insist on high quality work from themselves and from colleagues whenever that work impacts human health, dignity, financial systems, or other sensitive data. This includes respecting the dignity of employers, colleagues, clients, users, and anyone affected either directly or indirectly by the work. Professionals should be cognizant of the negative consequences that may result from poor quality and make conscious, transparent decisions when determining the level of quality needed for a project.