STL is good for what it is. The limitation is that there is little ability to specify behaviors, use cases, data distributions, workload profiles, etc because that would effectively break the abstraction and expose the internals.

However, STL still requires an implementation and so the implementors select algorithms that will give adequate performance across a wide range of scenarios but which are usually significantly suboptimal for any specific scenario. Consequently, a custom implementation tuned for a specific scenario will often handily out-perform the STL implementation. For the kinds of applications I work on, poor-fitting STL implementations are frequently major bottlenecks in the profiler.

It is plausible to add an enormous number of implementations and data structures to STL that would allow someone to select/construct the perfect data structure for a particular use case. However, that would also add a level of complexity to the STL that probably is not worth the benefit for many users.

I cannot speak to jandrewrogers specific reason, but the two major sticking points I've seen developers hit is the STL's bad allocator design and the lack of intrusive data structures. Check out EASTL for more information [1][2].

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... [2] https://github.com/paulhodge/EASTL

STL uses 'value semantics'. Just use push_back in a loop and observe how often the whole data in std::vector is copied. Not to mention std::sort.