My value to my user, customer, audience is NOT about how fast my programs go. It is a balance between :
timely delivery of the functionality,
correctness of the functionality,
documentation of the functionality,
and a bunch of other stuff.
Because of libraries and interfaces supplied by operating systems and language environments, we don't have to exercise the degree of control and detail that Assembly programming requires. This is a "good thing(tm)" in many circumstances - I don't want to write a new video driver every time I get a new monitor. It means I can use high-level languages to add value to someone else's data - such as implementing a Data Warehouse.
The corollary is that the further I am abstracted from the hardware, the less control I have. So I have to be careful about how I code my high-level statements (be it COBOL, C. Java or my image definition for HTML) if I want them to be efficient. And that takes time. Bear in mind that the other attributes of a good program or task still have to be met, and that time is not a finite resource. The trade-off that most people make is calendar time v 'good' (not just efficient code) programming in general (see the list above). In many cases, once the program or code or functionality is working and documented, work stops on it (until the next change).
But that paragraph assumed that I had the choice in the first place, that I COULD code efficiently for the platform that I'm using. And the only way that will happen is if I know the environment, the tools and the platform. But how do I learn to code efficiently ?
It's more than just knowing Assembly coding. For example, if you define a set of type java.lang.String constants in one java class, and then you update the class to change the value of any of these constants, you must remember to recompile all other classes that use the changed constants (p44 of O'Reilly Hardcore Java Ch2 The Final Story - I'm NOT a java guru, but its a referenceable example I was looking at on the weekend).
So, by trying to write efficient maintainable code (in this case, by using constants), the unwary programmer can cause more problems than they solve. Even if you know what you're doing, will the person who maintains your code ?
The nett effect is that the learning curve can be very expensive, and this (along with the other pressures on a programmer) mean that it can be a difficult decision for an individual programmer to take. It is easier to say "yes, i know its inefficient, but so's 90% of ALL xyz code".
Take this personally if you like, but if you say that, then you're not a professional. Even when it comes to playpen stuff, learn to code efficiently, learn to document (so that you remember why you did it this way), and learn to give a damn about your work.
This way you'll have the confidence to say "yes, I know that part is inefficient, but it is efficient where it matters".