Fortunately for me, smart people were having this same discussion 10 or 15 years ago (just as I got to the age where I stopped thinking I knew everything), and interestingly referring to Fred Brooks' work, presumably from the late sixties:
http://www.webdeveloper.com/cgi-perl/cgi_perl_style.html
"Think first. Then hack. Now throw it out. Repeat. Fred Brooks says, `Build one to throw away.' Always rewrite your code from scratch, preferably twice. just as did it with drafts of papers in grammar school. It improves understanding, gets the creative juices flowing, and produces a far finer end-product."
I would say that releasing software is more important than continually delaying for amorphous "quality" concerns, but this is backwards. You want to write quality software. I've been on several teams that valued speed over quality, and in the end we always end up with a sad, fragile bit of software that's hell to maintain or add features to.
> Of course, when you have a product that makes money you'll have to rewrite it, but by then you will have money to pay for developers...
Again, having been part of teams that operated this way: later never comes. Paying customers means people relying on your software. You can't just stop working on it to rewrite from scratch, and their bugs/issues/feature requests are far more important than refactoring (which they'll never notice.)
If you ever want good software, make it good from the start.
At this point in my life I can implement a well-programmed solution much more quickly than spaghetti code. Additionally I'd rather be proud of my work considering 99% of the time I will be failing at creating a successful product. If you care that little about programming then find someone to do it for you, but if you are actually a developer then I don't understand this haphazard approach. But then I suppose people are naturally lazy.
If you are coding as a means to an end, then by all means spaghetti code, but if you are actually coding because you like to code and subsequently like to create, then for the love of God take pride in what you do! This Black or White approach just does not make any sense in today's technical world.
I'd much rather see a sentiment of "never sacrifice architecture for functionality but never let architecture drive your features."