It just needs to be fast enough to fulfill the required tasks, not a blazing thunder.
This is how C replaced Assembly in many use cases, C++ replaced C in many use cases, ...
This is how C replaced Assembly in many use cases, C++ replaced C in many use cases, ...
In other words: You can write C++ that is no slower than C, and you can write C that is only rarely slower than ASM, and in both cases, in the few situations where the performance difference is large enough to be noticeable and matter, you can still easily write asm.
This is also why C and C++ keeps being used in the face of so many higher level languages.
And I say this as someone who spends most of his time writing Ruby, and who haven't even bothered upgrading to MRI 2.x despite the performance improvements available.
In other words: I agree with your first line. But moving to C/C++ is a totally different tradeoff than moving to most higher level languages, most of which at the very least makes the performance characteristics much harder to predict.
This is only half of the equation. The other half is what are the costs of the things you do use. E.g. costs of exceptions, virtual calls, dynamic linking, dynamic memory allocation, concurrency, etc. Java is like an all-inclusive offer - you get more at a higher cost, probably with something you don't need, but often it is cheaper than to buy every service one by one.
Of course, 30 years of industry investment into C compiler backends changed this relation.
Unfortunately, thanks to Sun and Microsoft VM über alles attitude in the past decade, young developers tend to equate higher level languages with VMs and think C and C++ are the only languages with proper native code compilers.
In assembly and C, but not C++, at least if you use exceptions:
http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
Of course you can pare down C++ further and further, but then you have C with slightly different type-checking semantics and you might as well move to a language where 'new' isn't a reserved word.