If you really want to accomplish as much as possible in your life, you could start by throwing out your prejudices. Computer languages aren't religions, they're tools, get over it.
Throwing out predjudices is always good advice. However, Paul Graham and others have argued (convincingly) that a language is not a tool. A compiler is a tool. A language is the actual medium that a programmer works in. It will effect every aspect of a software project, including the way in which the programmers think.
Sucks to your Sapir-Whorf hypothesis! That said higher-level languages do have real, non-mythical advantages over lower-level ones if one is trying to work quickly and with minimal effort. Good luck with your decision.
My point is that there are many really good, legitimate and numerically quantifiable reasons for using a high-level language that have nothing to do with the mythical, unprovable Sapir-Whorf justification.
As for the "tradeoff" I mean that high-level languages are particularly useful if one is primarily interested in minimizing development time possibly at the expense of other variables. Examples of "other variables" include processing time, memory usage, ease of hiring cog-like but adequate developers to maintain the system, company politics, etc. Such other factors are used everyday to justify the higher-effort solutions.
Does that make more sense? Sorry for any confusion.
Saying that the programming language conditions how you think is not equivalent to Sapir-Whorf. Think of it this way: an expert Lisp programmer using C++ will be very aware of the shortcuts, simplifications, generalizations, ... that he could be implementing with higher order functions, closures, macros, etc. He can have these thoughts even though he is using C++, so no Sapir-Whorf here. But many of these thoughts will only serve to cause him pain, since the required techniques are impossible or not worth it in the less expressive language.
Processing time is a real tradeoff, but you can go a long way if you get good at identifying the bottlenecks and translating the critical code to a faster language. I work in a massively multiplayer online game, which is a very performance sensitive application both client and server side, and most of our code is Python (and I think a good part of our C/C++ code could be ported to Python without significantly hurting performance).
Theoretically, high level languages should eventually perform better, not worse, than low level languages, as compiler technology improves, because the compiler has more information and freedom to perform optimizations. OCaml is a high level language which claims performance on the order of C.
Re: memory usage, I'm not convinced the overhead of higher level languages is a big deal, except for apps in very restricted hardware. Unless you mean cache coherency, which goes back to speed.
Re: easy of hiring, in my company we had some graphics guys picking up Python and contributing useful code in a very short time. We also had C++ programmers picking up Python easily, although I must admit C++ habits and idioms die hard.
That said, ease of hiring cog-like developers and company politics is not what I'd look for in a startup.
I admit I cheated by mentioning Lisp, OCaml, and Python to reply different points. Lisp and OCaml are less mainstream and not as trivial to pick as Python, which in turn is not as powerful or as efficient as these.
So yes, there are tradeoffs, but I wouldn't pick C++ as the pragmatic compromise, not even for big business. IMHO, Python + C (via ctypes) for close to the metal stuff would be it. For personal/startup work, I'd go for Scheme, and be happy to limit my hiring choices to people willing to learn that.
If you read my replies carefully you will realize that we are likely in agreement on many points and that you are putting words into my mouth.
As for the Sapir-Whorf argument the relevant case is not what the Lisp programmer thinks while programming C++ but what the only-C++ programmer thinks while programming C++. Are there thoughts he is not capable of thinking because he has not been exposed to Lisp (or any other non-C++ language)? I do not believe this is the case. How would Lisp have been invented if only Lisp programmers are capable of thinking at that level of abstraction?