It's never 1 vs. 2-3 days, the unit is rather months and years than days. Besides it's much more complicated than such an analogy can explain.
Sometimes you need to test some ideas. Then you focus on building a prototype that just "works" as soon as possible, so you can test. I've spent so much time wasting months and years building products that were just decided not to be launched at all at the end. It's a shame, but mostly not of programmers but managers...
Sometimes you have to make sure to get into market at the right time. Sometimes you have a pressure of a delivery for a client, sometimes you're competing and sometimes you have end-consumers that terribly need a feature...
It's always context-dependent.
First of all, of course there's standards but "quality" is relative. How do you measure quality? Is premature optimisation quality?
Nonetheless, time is easy to measure.
But I think fast & quality code is also possible, by selecting right open-source tools and not inventing the wheel, doing the right architecture from the beginning, and not having a co-developer who wanted to just learn and experiment a "cool" but super-unnecessary framework. Yeah, it's possible but rare, and not so often that hard...