Sound advise for general purpose programming but not for (high end) games.
Especially these days with multi-threaded game engines, a call to malloc() (e.g. from vector resizing) may attempt to grab a contended mutex and end up waiting until it misses its frame.
Modern game engines use a combination of memory management techniques which are tuned for different use cases. For example: large, persistent blocks of memory are allocated ahead of time. Small, transient objects are allocated from a thread-local, per-frame pool and they're never freed explicitly (at the end of the frame, memory will be reclaimed for reuse).
Most game engines don't use the C++ standard library containers at all in the first place. There are gamedev-flavored STL variants like EASTL, though.
For triple-A game engines attuned to work on console hardware, sure, but they're really sophisticated optimizations.
The STL is fine for a lot of things in gamedev.
Object pools are not so hard to implement, the only thing a object pool really does is to reduce memory allocation and de-allocation delays while keeping the O(1) random access. It's just a strategy for allocating and accessing memory properly.
It sounds like premature optimization, and it often is, because those strategies are not really trivial to use or implement.
