First off, MOST of the time in this day and age someone quotes that bit by Knuth, they are doing it out of context and as a lame excuse to cover up their laziness, their ignorance, or their unwillingness to change ingrained bad habits.
A great example of this comes from PHP -- the "single quotes vs. double quoted" strings argument where YES, single quotes ARE faster. The argument is the speed difference is so negligible it's not worth caring about -- but even if it is barely perceptible is it so horrible to just NOT hit "shift" on the same key? Or comma delimiting echo vs. string addition vs. double quote parsing. The latter two increase your memory footprint and are slower -- all of them are basically the same amount of typing so why do SO many use the "premature optimization" LAME EXCUSE to justify their shoddy coding practices?
Or even just something as simple as learning when to use SWITCH/CASE instead of IF/ELSE. You'll endlessly see people with massive bloated nested IF/ELSE again using the "premature optimization" LAME EXCUSE to cover up for their own ineptitude and/or ignorance!
Developing good programming habits and learning when and how to use the language properly IS NOT PREMATURE OPTIMIZATION.
YET you'll have people endlessly quoting Knuths:
Premature optimization is the root of all evil
But taken by itself that's OUT OF CONTEXT. It's a cute sound-byte sleazy dirtbags use to excuse their own laziness and stupidity. Let's look at the WHOLE text, shall we?
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small inefficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Oh gee, if I don't hit shift so I get ' instead of " making the 'effort' difference effectively meaningless falls squarely into good habits, have no negative impact when debugging or maintaining the codebase. Therefor his generalization DOES NOT APPLY!
This does NOT mean you obsess about it -- code clarity SHOULD be considered more important but honestly, more often than not over the past 40 years I've been writing software, clean optimized code is more often than not clearer and easier to work with! Again making the people who mindlessly parrot Knuth out of context look the fool.
But really, whenever ANYONE gives you a sound byte out of context, they're probably trying to lie right straight to your face. See the current trend of quoting one sub-clause from a letter of Lincoln's right now ignoring everything else said around it. Sound-bytes are classic for this, and one of the many reasons I think the twitter generation TLDR mouth-breathers are halfwit fools easily herded around that should REALLY pick up a book from time to time. See the illiterate derps who get their panties in a wad every time someone makes a post ANYWHERE longer than a paragraph.
Now, as to profiling -- that's ALWAYS important but you have to be careful not to let it LIE to you. I encounter this all the time in game development where time-slicing is a essential part of the process. Sometimes you ARE going to just have times where the computer HAS to sit there with it's thumb up it's arse waiting for the next frame update. A automated profiler will throw up a giant warning "hey you're doing nothing here" when that's INTENTIONAL to maintain smooth gameplay and framerate. Recognizing that is something a LOT of people obsessed with profiling tools often fail to grasp.
Profiling can also open your eyes to "Jeez, that part really didn't matter" as well as "wow, I NEVER thought that would be the bottleneck". See the classic BS we've heard from PHP developers that "well mysql is the real bottleneck, not the server side language" -- again, a LAME EXCUSE to cover up for shoddy coding practices. Had said statement that's been parroted for over a decade and a half ACTUALLY been true, then how in the blazes do systems like Laravel, Magento, and Wordpress see 80 to 90% speed boosts between PHP 5.6 and PHP 7?
Laughably, the engine under PHP seems to have been optimized to make shoddy coding practices run faster. THERE's some derp for you on the part of the development community. Almost as stupid as HTML's blindly plodding on as if nothing is wrong, wildly guessing at what the code should have been instead of stopping dead in it's tracks when it hits an error.
In reality, like everything else in development it's a balancing act where you HAVE to prioritize. How long can you take to code it? How important is its speed? How much improvement does this give me? Does using this 'faster' method ACTUALLY take any more or less effort than the "sloppy" way? How does the speed optimization impact code clarity.
There is no easy answer for this -- but you have to be EXTREMELY careful in making the determination that you do not bullshit yourself about it, or blindly accept someone else's lies and excuses.
You'll notice I use the word "excuse" a lot. MOST of the time, when people try to say why they aren't using the more efficient method -- especially when said method is no more or less effort -- that's ALL that it is. They've swallowed their own BS hook, line, sinker, and a bit of the rod.