I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time than you before, even if they seem to be obsessed with "beautiful code".
Most of the damage I've seen was from people who think they can write beautiful code, but instead write a slow overengineered framework and use clout to force everyone else's code into that framework. Sadly, these people are often smart and experienced. It's more of an attitude problem: they are not content with making a library that will sit at the bottom of the call stack, when they could instead make a framework that sits at the top.
I've worked at a couple companies now that have this problem. I know that one is now on their third try at a second gen rewrite of their aging core product. They can't ship it because they haven't found that magic formula to make it the most perfect program ever[0]. Sadly, this has been with multiple teams trying.
[0] I call this the Neo Architecture. They're looking for "the one". The architecture that will allow for any CR to be handled elegantly and beautifully, where all concerns are completely separated, where all data is perfectly abstracted. There's no such thing. It doesn't exist. Just ship already!
> I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code
Because people who write "beautiful code" don't often achieve anything that can be seen. Successful companies are based on quickly written code that delivers.
