All languages should not try to incorporate every feature of every other language.
C++ is essentially a very, very sophisticated macro assembler. It is NOT (in a traditional sense) a high-level language like C#, Java, Objective-C, Smalltalk, etc.
It is good to have different tools for different jobs. If we only have hammers, all things are going to look like nails, etc. Having script languages is useful for some jobs, and reflective OO-languages (Java, Obj-C, C#) are useful for another class of jobs, and super-efficient bare-bones close-to-the-machine languages are useful for yet another class of jobs (C++, C, Assembler).
C++ does an amazing job of extending Assembler technology to incredible levels of complexity management, and abstractions to make programming larger, more complex tasks vastly more possible for human beings. But it is not necessarily a language that is the best suited for those who are approaching their problem from a strictly high-level perspective (Lisp, Smalltalk, Java, C#). If you need a language with those features to best implement a solution to your problems, then thank those who've created such languages for all of us to use!
But C++ is for those who, for whatever reason(s), need to have a strong correlation between their code and the underlying machine's operation. Whether its efficiency, or programming device drivers, or interaction with the lower-level OS services, or whatever, C++ is better suited to those tasks.
C#, Java, Objective-C all require a much larger, richer runtime system to support their execution. That runtime has to be delivered to the system in question - preinstalled to support the operation of your software. And that layer has to be maintained for various target systems, customized by SOME OTHER LANGUAGE to make it work on that platform. And that middle layer - that adaptive layer between the host OS and the your code - the runtime, is almost always written in a language like C or C++ where efficiency is #1, where understanding predictably the exact interaction between software and hardware can be well understood, and manipulated to maximum gain.
I love Smalltalk, Objective-C, and having a rich runtime system with reflection, meta-data, garbage collection, etc. Amazing code can be written to take advantage of these facilities! But that's simply a higher layer on the stack, a layer that must rest on lower layers, that themselves must ultimately sit upon the OS and the hardware. And we will always need a language that is best suited for building that layer: C++/C/Assembler.
Addendum: C++11/14 are continuing to expand C++ ability to support higher-level abstractions and systems. Threading, synchronization, precise memory models, more precise abstract machine definitions are enabling C++ developers to achieve many of the high-level abstractions that some of these high-level only languages used to have exclusive domain over, while continuing to provide close-to-metal performance and excellent predictability (i.e minimal runtime subsystems). Perhaps reflection facilities will be selectively enabled in a future revision of C++, for those who want it - or perhaps a library will provide such runtime services (maybe there is one now, or the beginnings of one in boost?).