Yes, I agree that Premature Optimization is the Root of All Evil, at least within the programming paradigm where this concept arises, and likely true in a much broader concept also. If you're a developer, and you think about it (just stumbled on this idea here, your search engine will give you more examples), you'll likely agree it's true.
But do you know why this excellent insight presents a challenge which is hard to overcome, particularly for software developers?
It's because the skillset that makes an excellent programmer is the skillset of someone who is excellent at premature optimization. The "good" side of premature optimization is that it is a form of pattern recognition... and pattern compression. Writing code is a matter of writing an extremely concise version of an idea, one portion of the idea at a time.
Writing code itself is a form of optimization, a logical distillation of a more complex intuitive idea.
So although Premature Optimization is the root of all evil, the solution is not to eliminate the problem, but to get better at identifying *what is best optimized*. The recommended approach is to just write the code, get it working, and then come back later and optimize.
This is a great first step, but you should be able to see that you can go too far in the opposite direction here -- writing big, sloppy, spaghetti code that needs to be completely rewritten from the ground up is an inefficient way to do things. Being able to find that sweet spot between the two extremes -- premature optimization on one end, and no optimization on the other end -- is the art of programming well, and it takes years.
I call this Mature Optimization. The ability to see and code in such a way that your first implementation is optimized structurally in such a way, that when you work on your second iteration, you're not rewriting the whole thing.