Judging a C++ framework by whether it implements its own string type probably isn't a good idea. C++ is inherently limited, and a string type is often the only way to have certain design guarantees. In a performance-critical context, it's sometimes crucial to control the exact pattern of allocation. And not just how they're allocated in memory, but also how often they're allocated. You can control std::string's pattern of allocation by using a custom allocator, but you can't control how often std::strings are created, for example, because std::string implements an interface which is guaranteed to construct temporary strings. This normally isn't a problem, but in contexts where every millisecond is crucial (like gaming) this can be disastrous, since it's very hard to optimize the performance characteristics of std::string once it becomes pervasively used throughout your codebase.

Another reason to make your own string type is for proper unicode support. Maybe C++11 or C++14 added features to help with that, so maybe this is less valid nowadays. I haven't kept up.

That's a pretty low bar...