std::string does not have the same character size and behavior on each platform, which will be messy if someone makes bitwise operations on characters or suddenly need to support Chinese characters in a parsing algorithm. Working on an 8-bit string format encoding UTF-8 is almost guaranteed to introduce bugs from cutting characters in half and would add lots of bloat to all algorithms. Better to have a custom string type that always store the non-encoded 32-bit value representations of Unicode, just like in the .NET framework. One element is one character and then just save as UTF-8 by default when saving to files for compression. There are 32-bit versions of std::string, but these have the same design flaws as std::vector leading to poor performance.
std::iterator (deprecated in C++17) is very unfriendly to beginners, hard to debug, preventing SIMD vectorization, and not providing any benefit over indices. Iterators were supposed to abstract away the difference between arrays and linked lists, but linked lists are only used when spending a long time in each element or only working on one element at a time. For high level code, better to use indices so that you can see how the algorithm executes while debugging. For high performance code, better to stick with arrays and bound checked pointer abstractions.
std::vector has a poor allocation strategy (lots of tiny initial allocations smaller than a cache line), does not align memory properly, forces the use of iterators for certain operations (leading to dangerous code for no reason), uses unsigned indices (cannot loop backwards while x <= 0u, due to unsigned underflow). For high level code, you can write a wrapper around std::vector, but never use std::vector in high-performance iterations. The worst part about std::vector is how people use it as a substitute for std::array, just because std::array cannot use a variable length at construction, leading to pointer crashes if the std::vector reallocates with old pointers to elements.
The Chrono API is okay to use, because it's just a clean hardware abstraction allowing you to target operating systems that have not been created yet. Just need someone in the future to recompile the code and publish a remake. Better than having contemporary hacks that are guaranteed to fail as soon as the current OS fad dies out 50 years from now.
std math is harder to decide on, because writing std::max(a, b) does not feel like using a core language feature, making the std namespace implicit would be even worse due to constant changes, making inline wrappers over trigonometry in a new namespace would still expose std math in the header. The C math library does not support overloaded functions between float and double, which makes the expressions look strange. It's just a terrible mess of legacy and not knowing what to use.
It would be nice if lambdas did not force use of the std library, because it totally blurs the line between core language and optional features for anyone wanting to use modern C++ without std. Don't want to write a class just to re-implement the Lambda type. Should be an intrinsic language type just like function pointers, but that would break backwards compatibility with older projects.
std::move and std::swap are also core functions that somehow ended up in the std namespace. Implementing them yourself would be too dangerous to even try, due to all the heap hacks used in compilers to make everything work.