I agree that programmers should know the difference. But I don't let them abdicate their responsibility when you get there -- they should also know how to use the tools to manage that stuff for them.
You're not paying for anything. "STL containers" have been an integral part of every compliant C++ compiler since the 1998 standard. I disagree with the "no need to use them" philosophy, in preference to the "why wouldn't you use them" when they're a standard part of the language library -- they are a defacto part of the compiler's tool set.
Try to think of this modern C++ paradigm as an entirely different language rather than a super-charged version of C.
And the cost is also minimal in the compiled code. STL containers specifically, and templatized code in general, typically compile down quite efficiently with modern compilers. The runtime performance is quite good as well, because this is templatized code and not a bunch of runtime magic.
I agree with you that none of this stuff should be magic, and that the programmer should understand how it works and how the memory usage is handled underneath the covers. That said,
RAII is one of the most powerful paradigms in modern C++ programming. Embracing it more widely would result in much higher quality programs with fewer lines of code.
... but... I understand where you're coming from. Using C code for very tight engine code is an understandable choice for the same reason as using assembly to make platform-specific high performance string functions. My point of view is from a more general application development perspective. But don't make the mistake that C++ can't be performant enough in many situations. I have friends who do embedded development, and even they are starting to move to C++ because they simply can't deny the benefits of some of these higher level paradigms any longer, and the size and performance cost of using C++ are not significantly worse that C any longer in many cases.