EA developers weren't happy with STL, so they created their own version, EASTL. One of their complaints had to do with custom allocators: STL allocators combine allocation and initialization.
Ziglang has done a lot of interesting work here as well. They have no default allocator - things in stdlib that require allocation require you to provide one, but you get a decent selection of different allocators in stdlib to use for various use cases.
Isn't this somewhat mitigated by the introduction of std::optional<> in C++17? By using it optional<T> instead of T, you can allocate storage while deferring initialization to a latter time (using emplace() or operator=, if T is either moveable or copiable).
Perhaps somewhat, but it adds an extra layer of (often) unnecessary complexity. This is especially the case which comes up often where you’re interacting with external libraries or even your own internal, older libraries. For example, if you have a vector, and want to pass its contents to a C API that takes a pointer and length. If it’s a vector of raw values/structs, no problem. If it’s a vector of std::optional<Foo> now you’re stuck unless you go through and recopy the whole thing.
That being said, I’ve never found the STLs use of initialized allocation to be a problem, but I don’t work in game design.
But the criticism is still questionable: an allocator can define ::construct() not to do anything, and leave actual construction to user code.
A few more of the criticisms are addressed in C++11 which fully support stateful allocators; they were not mandated (but still allowed) in C++03 because some implementors felt that the STL was too much work to implement already.
Most of the rest are QoI issues, and it is perfectly reasonable for EA to have its own STL implementation that give the same guarantees across platforms, but it is not a criticism of the standard itself.
Be careful that 'trivial' is a term if art in the context of C++ initialization. Having to do work is different than not having to do it. Constructting a vector of N optionals is O(N) as opposed of a vector of a truly trivially constructible type, which is O(1) (although I'm not 100% sure if the standard guarantees it or it is just a QoI).
Reading their critique of STL design decisions, as well as of their own, might be useful here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...