[mekoka]

In order to learn from a "mistake" there needs to be some sort of feedback. Many programmers make the same mistake over and over because it hasn't yet come back to seriously bite them in the ass, or because the evidence of it isn't clear. Only then is the mistake corrected and the lesson learnt.

For example, in this day and age of fast processors, abundant memory, large hard-drives, you can't expect a novice to put much emphasis on efficiency. He'll code and will run his program just to see the output appear almost instantly. A veteran will look at it and shake her head, but that's because she knows that back in her days, code this inefficient guaranteed that you'd spend the day in the lab just waiting to see the first letter of the output. Don't expect the newbie to learn that lesson any time soon, with his blazingly fast laptop, on which he's working comfortably from his bedroom. Now, hand him one of those snail computers at his next internship and watch the transformation operate.

[commanda]

If it never comes back to bite you (or anyone else) in the ass, was it really a mistake?

[jerf]

Taking your question literally and in isolation, no.

But the manifestation more relevant to the real world is not having the experience base to realize it's biting you in the ass. Specifically, even though X is working, it could be working better, for less effort. Or another common case is X is not working and you misidentify why ("lazy developers not willing to do the work" instead of "used the wrong paradigm for the job", for instance).

[Splines]

True enough, needless optimization is often unnecessary.

The difference is that an expert will be able to make a good decision about that trade-off. A novice is restricted to the tools and practices they are familiar with - they might come to the same conclusion, but not for the same reasons.