One really has to think of the WHY behind such idioms. The reason for not beginning to early are that you might not know what the real bottlenecks will be and therefor sacrifice readability and time for finishing an early version, which would actually allow you to have a look on how things work in practice. Usually you want to have some kind of small prototype/proof of concept to follow other idioms, like "release soon, release often" or "small is beautiful".

Also it depends on what you actually do. If you want to create something where you mostly care about performance it's not like you'd start when everything is already finished. Another thing is that such idioms are important to make you a good programmer writing good software which isn't always what you want to do in real life. Often you just care about making money or pleasing your customer/boss.

Think about Sun Tzu. A lot of people in the military read his books. He was very experienced and had a lot of knowledge, still it may be impractical to follow his idioms, even if they are one hundred percent correct in every situation.

I guess the world would be better, if everyone would listen and _always_ follow guidelines, as the UNIX philosophy, but the current situation real word sadly adds a lot of variables which cause you to ignore them.

Or in other words: It all depends.

Or to quote Einstein: All things are relative.