You're obviously not familiar with the research on software development and productivity. I would strongly suggest that you pick up some books from Steve McConnell (eg Rapid Development) as well as some classics like Peopleware. You may find some of the lessons invaluable.
Researchers have studied variation in speed of development between programmers. A common scenario are coding tests where different programmers are asked to do the same task. These studies have consistently found differences in speed of a factor of 10 or more. Follow-up research has found that programmers at the fastest end of that scale spend the smallest fraction of their time actually programming. Instead they spend time in other activities such as design and testing. So time invested in design and testing pays back during development. And not just in a large project, but in a sample coding exercise of less than a day.
Here is another data point of interest. Another study assigned multiple professional teams the same project, but asked each team to optimize a different thing. A few of the dimensions were performance, development speed, maintainability of code, and memory usage. Most of the teams managed to win on the characteristic they were optimizing for. The team that was aiming for maintainable code came in second on most of the other dimensions.
When you consider that as an industry we spend about 70% of our software development dollars in maintenance, aiming for maintainable code has lopsided benefits relative to the other options. Your code is done almost as fast as possible, performs reasonably well, uses a reasonable amount of memory, and costs a lot less to maintain. Situations exist where that isn't the optimal trade-off, but it is optimal often enough that it should be treated as the default.
I'm quite familiar with the research ("Code Complete" is a book I constantly reread) and with the arguments for good design. As another commenter pointed out, the argument wasn't so much for "perfection" as it was for "good code" (which I can't argue with). It's still somewhat arbitrary, thought, and the more "good" it is the more you edge into diminishing returns. There's some point where the trade-off for "better code" trails off.
Design, however, is a whole 'nother ball game. As you pointed out, research has shown that most of the problems, and indeed the most expensive problems, are caused by requirements. (IIRC)
Researchers have studied variation in speed of development between programmers. A common scenario are coding tests where different programmers are asked to do the same task. These studies have consistently found differences in speed of a factor of 10 or more. Follow-up research has found that programmers at the fastest end of that scale spend the smallest fraction of their time actually programming. Instead they spend time in other activities such as design and testing. So time invested in design and testing pays back during development. And not just in a large project, but in a sample coding exercise of less than a day.
Here is another data point of interest. Another study assigned multiple professional teams the same project, but asked each team to optimize a different thing. A few of the dimensions were performance, development speed, maintainability of code, and memory usage. Most of the teams managed to win on the characteristic they were optimizing for. The team that was aiming for maintainable code came in second on most of the other dimensions.
When you consider that as an industry we spend about 70% of our software development dollars in maintenance, aiming for maintainable code has lopsided benefits relative to the other options. Your code is done almost as fast as possible, performs reasonably well, uses a reasonable amount of memory, and costs a lot less to maintain. Situations exist where that isn't the optimal trade-off, but it is optimal often enough that it should be treated as the default.
Which is exactly what this article was arguing.