You’re not wrong in principle, but I think it is absolutely fair to expect a standard library to include a good hash map implementation. These aren’t unreasonable demands.
The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
The stdlib's unordered_map could certainly have been designed better but there have also been significant developments in hash map implementations since it was added so no matter what they would have specified it would be obsolete by now. Meanwhile adding your favorite hash map to your C++ project doesn't take long at all. The only issue is if you want to pass a hash map between different libraries - there a standard type would be useful. But that also requires a stable implementation that doesn't change which gets the same ossification of sub-par implementations that you already have in the stdlib.
The larger point here is that the ossification is a direct result of the combination of two things: the way that monomorphization works, and wanting to maintain ABI stability in perpetuity.
I don't know how to solve it, but it's clear that C++'s general utility is severely hampered by this ABI stability crutch.
The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.