To me that has always been a lame excuse for a poor standard library. You can always build your own, even if the standard library has a solution that works for 99% of cases - and that makes 99% of code more readable to 100% of people.
I love C (let's not get into a C++ rant here..) so this is just a comment about the culture, like the parent post. The fact that people who don't like to re-invent the wheel have not stuck with C, and maybe gone to join the Perl, Python, Java... communities made this issue worse over the years.
In theory, this could still be done now (e.g. a standard build system), but I think most "systems language" innovation action now firmly happens in the Rust camp (which may be a good thing, because the world needs more safe code).
UTF-8 saves space and is just as easy (and fast!) to process as UTF-16, as both are variable length encodings. UTF-8 is always unambiguous and self-synchronizing. The byte order stays always the same. The only complication is potentially multiple ways to encode a character, but that can be solved by just declaring all but the shortest encoding illegal.
Hopefully we'll only have UTF-8 in the long run, both externally and (by default) internally.
C string functions are mostly compatible with UTF-8, as long as individual non-7-bit characters are not processed or the string indexed, etc.
[1]: https://scattered-thoughts.net/writing/against-sql/#innovation-at-the-implementation-level-is-gated