The standard library has a bunch of requirements that a random third party library likely does not have. Like ABI compatibility (most people recompile from source often so it isn't needed). Like exception safety (most people turn off exceptions anyways so they don't need such safety).
Some parts of the standard library like std::vector is already good enough. Other parts like std::unordered_set are rarely used in industry unless low-dependency is a requirent.
Define most here a little bit more. I would imaging most people using it are hobbyists/students and, in that case, I think you're right.
But most people using it in industry fall into two camps:
1. using it because the project is old enough that C++ was a reasonable default when the project started. You may also be right here
2. using it because performance is absolutely critical to the application, here I would actually imagine you're wrong. noexcept removes a ton of stack-unwinding code, and you can absolutely get a significant performance boost out of it. It would be weird if they didn't pull this lever, given the perf boost and that errors as values is also a fairly reasonable way to handle problem
In the second category, google famously had a "no exceptions" rule at one point (could still be in effect, I have no knowlegde of google)
> Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
I see noexcept as a part of the language that works together with exceptions, it is a valid optimization for certain (typically small) pieces of a code base that otherwise uses exceptions.
I'd imagine when people say "not using exceptions", it is about using compiler flags to completely disable the exception mechanisms from the language. And this also invalidates many of the design patterns C++ is known and sometimes praised for, at least RAII and operator overloading.
ABI compatibility is needed in 99% of the cases since you basically never compile your own STL. You dynamically (or statically if you will) link against the one you have on a system since most software does not have a control over the machines/environment where it's going to be deployed. Even in cases where you do have a control over your environment deployment, compiling your own libc++/libstdc++ is a complication which you usually want to avoid.
The fact that you will use a class or function template from STL, and compile it, doesn't change the fact that, regardless of that, you will have to link against the libstdc++ or libc++ which you didn't compile yourself. I am not sure I understand the argument you're trying to make.
Some parts of the standard library like std::vector is already good enough. Other parts like std::unordered_set are rarely used in industry unless low-dependency is a requirent.