C++ attempts to do anything you can imagine.
You can't please everyone all the time, but you can please some people all the time or everyone some of the time. Many languages out there specialize on one task.
PHP makes web programming easy for anyone, for example. C++, if you choose to learn it, is
the right tool for nearly every job. It just has so many
features that there's almost nothing it can't do.
This is more or less the purposeful direction of the ISO 14882 standards committee. If there is something that could possibly be practical in C++ - say, a flexible functional language for implementing metacompilation algorithms - the committee will recognize it as an important potential use. Through the BOOST header library, there is an established path from experimentation to standardization. Furthermore, the standards committee holds regular, open meetings where technical progress actually occurs.
Why is a jack-of-all-trades so useful as to attract such research effort, not to mention the energy it takes adopters to learn such advanced (but unfriendly) features as MPL?
C++ is remarkable in being as portable as C, while remaining a compiled language. With the exceptions of a few of the most popular functional languages (i.e. SML and OCaml), Fortran, and ADA, every compiled language out there has serious issues with platform support. Vice versa, most portable high-level languages (e.g. Ruby) are interpreted. (Languages which are translated to C, such as Perl still correct?, suffer from language translation being a sometimes lossy/bloat-inducing process - incurring the same problems as interpretation, although to a lesser extent.)
C++ is fast and memory efficient. Many compiler engineers go to those standards meetings to hear out what programmers are really doing. Immense engineering effort is then spent making those high-level constructs compile well. If you think C++ is slow, you haven't seen a recent compiler. It is incredible to me to plug in a huge morass of templates, and see the compiler produce just the right instructions to accomplish whatever all the template hand-waving was about. A properly written C++ program generates a few instructions with a lot of code.
Besides that, C++ is one of very few high-level languages to give the programmer complete control over memory management. The runtime is simple almost to a fault, and it's really composed of a set of optional features. Disable the features (a la EC++) and you can ensure really slim requirements. Then, you can have the language "internals" call your allocators and it's all good. In fact, no runtime library is even necessary for most high-level operation.
For example, any random programming interface in C or C++ can be mapped to using C++ templates. Say you have several unfortunately redundant interfaces existing in your project, and you can't really eliminate or unify them. C will let you write a map from several interfaces to one engine, which might help performance. But confusion is as much of a problem as performance, if not more! It's really nice to have only a single interface for a particular job. First, encapsulate the relevant state information and procedural idioms into a C++ template. Then, use template specialization to implement glue from the common interface to each of the redundant components. When you want to write some new code for the crappy interfaces, call the template and tell it to adapt appropriately for the crap interface you'd otherwise be using. You can use a single interface for all your existing messy, heterogeneous code!
Bonuses on the above include friendly type-error messages when you get confused about which interface you're supposed to be using, and instant translation between the interfaces if you implement a copy constructor for the template.
In conclusion, C++ gains unique abilities from being a copycat. Software fires result from the language not supporting desired constructs, or for myriad other reasons. C++ is a fire hose.
A'course, in the wrong hands, a fire hose can be very destructive, too.