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.
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.
I personally am more conservative on those things. I'll pick the fastest thing that is reliable.
We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.
That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.
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 checkingMost of the rest of us STL is good enough.
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.
The ABI Nightmare - The C++ committee has this extraordinarily weird and strict rule: never break the Application Binary Interface (ABI). If a better algorithm or memory layout is discovered, the standard library cannot adopt it because doing so would change object layouts and break existing binaries. The worst part is that this ABI is never defined, so you always HEAVILY pay for what you DON'T use.
std::regex - the Programming Language Joke of the millennium. Even an interpreted language regex engine runs faster.
std::map, std::unordered_map - outdated, badly-designed and slow crap that is beaten even by high-school coders writing map data-structures.
No bounds checking. And Undefined Behavior by Default for operators like std::vector::operator[]
std::iostream - bloated, expensive design, std::vector<bool> - another joke.
Silent Iterator Invalidations causing unpredictable memory corruption.
No deprecation strategy. There are FOUR callable wrappers. At-least, have the courage to say @DEPRECATED.
No Standard Networking.
Missing System Utilities - nothing for process management, standard cryptography, or basic command-line argument parsing, etc.
To be honest, this is just the common complaints - if you run through all the stdlib features, there are dozens of severe problems. Which all the smart people know about, but are forbidden to fix - because of ABI!