We know programming is not incremental, often what we did to get 70% of the requirements will be completely useless to achieve the remaining 100%. C++ will take you everywhere, and I find it a solid choice for any project especially because I am often unsure of performance requirements. I can confidently say my C++ code will scale.
So will wire-wrap, but are you going to try wire-wrapping a word processing program? C++ is able to do anything that Lisp, Haskell, or Scala can do, but with at least an order of magnitude more work for any non-trivial project. That order of magnitude can make a difference in getting your project done at all.
"I can confidently say my C++ code will scale."
I can say the same about my Lisp code. In fact, I switched to Lisp to improve scalability over the original C++ codebase, because improving scalability required a higher-level approach. Sure, it could have been done in C++ -- which would have added at least a month of extra work, which I really cannot spare right now.
We all know that the C language is more a low-level system language than it is something else. Especially for this "something else" the use of other languages thrived. C++ since its appearance brought continuously on the table things to cover these higher levels of programming. This is what makes C++ a language that "will take you everywhere". Use newer incremental additions and you will do what Lisp, Haskell or Scala does without that "order of magnitude more work".
"C++ since its appearance brought continuously on the table things to cover these higher levels of programming."
I see two issues with this statement:
1. The attempts to bring high-level constructs to C++ seem to always come up short. Example: it is still not possible to create something as simple as a doubly-linked list using the standard automatic memory management constructs in C++.
2. Low-level issues creep into high-level constructs rapidly and conspicuously. Example: you have an iterator pattern for sequence types, but if you are not careful you can create a dangling pointer (and no exception will be thrown).
This is why I say (and why my experience has been) that C++ adds an order of magnitude of work to any non-trivial project. The high-level features are poorly conceived and muddied by low-level issues.
Assembler will always scale too. The fact that something will always scale does not mean that it really is the proverbial golden hammer. Assuming that you will need scalability for any project regardless of what it entails is premature optimization.
There are also any number of cases where by using C++, you are missing the opportunity to use something more sensible. Some example use cases include data processing using massively distributed Hadoop installations, data analysis using Matlab/Octave or R, scripting using shell, perl, python, or ruby, and web client programming using JavaScript. I can't imagine web client programming counts among your "anywhere", but if you are doing all of these other things and doing them in C++, then I must ask why.
And in my personal experience[1], developer velocity has proven to be much higher in, say, Python than C++, and there are any number of use cases where rapid development is more important than scalability. Do you really find C++ to be the fastest language for a team to develop in (in your experience)?
ASM doesn't scale in structure (impossible to manage) and certainly not in architecture - for example new Intel Haswell's have vectorization opportunities which will cause any code that doesn't use these opcodes to run worse.
Lastly, it is increasingly difficult to beat C/C++ in performance using handmade ASM, especially when comparing tight loop performance in handmade asm and intel icc - although maybe I suck.
Web-client doesn't count in my anywhere because my browser doesn't run a compiled language. That being said backends are often written in C++. A frequently used paradigm is to see some glue language java, python, calling critical C++ routines that are exposed as a library.
