1) Because you can insert the same object, rather than pointers to the same object. In addition to fewer memory allocations (zero vs 2), it makes finding the object in the second hash table very fast - no search required (see IntrusiveHashMap::iterator_for). It also simplifies key management, because it's not necessary to split out the keys or duplicate them (although this is a property of the particular implementation, not fundamental to intrusive hash tables).
2) There's lib/ts/MT_HashTable.h. Ones in lib/ts/Map.h, such as HashMap, HashSet, ChainHash, StringChainHash, and NBlockHash. Yes, I don't expect my work on hash containers in TS to be on the cutting edge of hash table implementations. But neither is the STL AFAICT (or people wouldn't be using substitutes). This isn't a huge, long term project, it's 723 lines that are mostly comments. Interestingly, though, proposed methods on containers for C++20 indicate a move toward intrusive hash table properties for STL containers, primarily the ability to move nodes from one container to another without allocations. I don't have any performance measurements for IntrusiveHashMap. I will see if I can get time to generate some.
