Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.
These are all optimisations that I have tested and profiled though.
The problem I see is when doing applications where doing the work in 100ms or 1s doesn't matter at all.
Yet one will be discussing about bounds checking impact, if i++ or i = i + 1 generate the same code and many other micro-optimizations.
For the type of work I do, I always embraced the STL and never though a second about those issues, yet I was able to fulfill the expectations.
Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one.
And by correlation the C sub-communities from C++ and Objective-C ones.
Other communities think first into getting their data-structures and algorithms right, use the profiler and then optimize.