I'll be the one going against the grain here and say, it is never too early to learn about optimizations, especially assembly optimizations and more importantly, debugging in assembly. I believe that you will gain the maximum benefit of it if you are a student (because then you have very little to lose [i.e. time/money wise]) and everything to gain.
If you are in the industry and not tasked with tinkering around in assembly, then don't. Otherwise, if you are a student or have time in general, I would find the time to learn to disassemble programs and see if I can come up with a better solution than the compiler. If I can't, who cares! I just learned how to write as well as compiler and that is a HUGE plus when you are faced with a bug in release code (with no debug symbols) and staring at the disassembly because that's the only thing you can look at.
This is one of the best resource I have found for learning about optimizations.
If you read some articles by major developers (for example, reasoning behind the making of EASTL and closer inspection of the code will lead you to comments like did this because GCC is terrible at inlining this if statement which will tell you, what the majority of people tell you trust the compiler is not always right, ESPECIALLY in game development) and then set foot in the industry you will find that optimizations are an everyday thing and knowing what the assembly output means is a big plus. Also, people don't seem to realize (especially on stackoverflow) that profiling games is very hard and not always accurate.
There is a caveat though. You can spend time optimizing something and later on realize that was time wasted. But what did you learn? You learned not to repeat that same mistake in a similar circumstance.
What SO is now taking is in my opinion a religious stance to the statement don't optimize until you profile and don't worry, the compiler knows better than you. It hinders learning. I know experts in the industry who are paid very good money (and I mean VERY good money) to fiddle around in assembly to optimize the game and debug it because the compiler is bad at it or simply cannot help you, because, well, it cannot (GPU related crashes, crashes where data involved is impossible to read in a debugger etc. etc.)!
What if someone who loves doing that, hasn't fully realized it yet, asks the question here and is turned away/off by the many answers compiler knows better than you! and never becomes one of those highly paid programmers?
One final thought. If you start doing this early, you will find that soon you will start writing code that is at worst, has no performance improvements whatsoever because the compiler optimized it the same way or at best, has some performance improvements because now the compiler can optimize it. In either case, it has become habit, and you are no slower at writing code this way than what you did before. A couple of examples are (there are many more):
- Pre-incrementing unless you really want post-increment
- Writing loops for containers using a constant local size variable rather than calling size() on the container within the loop.
EDIT: Update after 8 more years in the industry. Learn assembly. Learn how optimizers work and the assembly they generate (CompilerExplorer is a great tool for that). I have run across countless crashes in Test builds (optimized builds for internal testing) where you cannot rely on the debugger even with debug symbols. The compiler has optimized out too many things and the assembly is your only source of valuable information to find the bug from the crash dump. Each build takes 30-40min if you're lucky and first in the build queue - so you cannot rely on some traditional techniques to isolate the bug. Multiplayer makes things worse. Knowing assembly and how to read optimized assembly will simply make you better and ultimately more valuable to the team.