Used properly C++ is very appropriate for embedded work.
And when used improperly C++ is very inappropriate for embedded work.
Actually, I think the OP has an important and valid point regarding the nature of C vs C++.
C is "small" langauge. Compact, purpose designed to build an OS (Unix, of course.) There was only enough added to the language to make it do what was needed, no more. It was designed to keep the programmer "close to the metal".
C++ is a "large" language. It was developed because for _very_ large projects, C lacked some features that made maintaining and re-using code in large code bases more manageable. In C++, the "metal" can seem a long way away.
But there's the problem. A lot of C++ has to be avoided, or treated very carefully, when doing embedded work. As a large language, with lots of (often redundant) features (redundant in the sense that it gives you several ways of accomplishing the same thing), if you aren't careful you can easily get code bloat with lots of stuff being wheelbarrowed in under the hood, so to speak.
So what is an embedded programmer to do? Simple: you ruthlessly "subset" C++, to just the bits you need, and everything will still be fairly efficient.
And guess what? That subset looks pretty close to original C! Funny, that.
Now, there is a bit of "syntactic sugar" you get when using C++ over C, even in the heavily subsetted form. You can use methods and classes rather than structures and functions, which are tied together a bit more closely, and perhaps more elegantly. But do you really _need_ all that additional data hiding and abstraction in an embedded project? Probably not. A well-written and structured pure C program for an embedded project will probably be just as maintainable and manageable as its well-written C++ counterpart. The code base is never going to get so large, and the programming teams maintaining it so large that the language differences really kick in to affect productivity.
And, as a final word, watch out for that string class. :-)