Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature.
You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time.
NIH implementations are usually grossly inferior because as it turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.
Sometimes there are ways of getting runtime bounds checking.
For example, both of these return the 3rd element of a std::vector:
auto val1 = vec[3]; // no bounds checking
auto val2 = vec.at(3); // bounds checking
> bounds checking in release builds
Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).
The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, everything) was somewhere in the 2..3% range, which is fine when budgeted for upfront.