You've got some valid points there, but I don't quite understand the link between technical quality and coding standards.

Of course coding standards are important to make code readable, but for example if a program is well readable, virtually bug-free but has trailing whitespaces on some lines I'd still call it "perfect".

So you should start thinking about which quality measurements are important to you. Coding standards shouldn't be the no. 1 priority.

BTW there are counter examples to your "don't make it perfect" statement. One thing that comes to my mind is Donald Knuth's TeX program, that was virtually bug-free and thus nearly perfect. It has incredibly low maintenance costs because only a few bugs have been found so far.

So you can come quite close to perfection, and if you want your software to persist for 20 years, and keep bugfixing affordable, try to get as close as you can.