Language efficiency is irrelevant in most domains; otherwise the dominant constraint on efficiency tends to be improper thinking. Languages can improve this by encouraging reuse, but in reality this seems not too significant. To my eyes improper thinking's dominance comes from within established abstractions which may or may not be language dependent.
Now clearly there are domains where language efficiency is relevant. Typically this happens when you're running at scale, or when many potential users are precluded access due to performance even after all major errors in thought have been removed. ( note real-time systems are excluded from this list as the issue there is not performance but consistency ) With this in mind I posit that one should care exactly when you think you might end up in this scenario, and not otherwise. Even in this case it's likely that only parts of the application need to be written in an efficient language.
This is my opinion anyway.
I agree with >>17, language efficiency is irrelevant in most domains. It is typically applications with "large scale operations" that demand tight resource constraints; there's plenty of applications that don't have such constraints.
For the work that I normally do, programmer time is significantly more expensive than computer time. The programmer time cost of iterating and proving logic is normally more important to me.