It depends on the contributors, but boost also almost always fails to consider performance implications.

For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time.

The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.

Boost has its uses and in many cases it's an improvement over the standard library, but performance isn't one of its key properties. Some parts of boost are about as fast as they can be, but that's the exception.

I have never once seen Boost seriously considered in performance environments.

Even if somebody put such a thing, or two, in the standard library there would be again someone showing that they managed to come up with a better solution. For their workload. And under constraints that are only valid under their use-case and constraints that only they would know. Not standard library developers. And that's the thing - the premise that "one size fits all" even exists is wrong. I used to think that way as well but generic solutions to high-performance algorithms do not really exist.