From the rationale page of the documentation, it appears that one of the intended applications of a tokenmap is in the implementation of state management on top of an otherwise stateless protocol (such as HTTP). With HTTP, a common trick of tracking state (whether a user is logged in, their username, etc.) is to set a cookie that contains a session id. The client stores the session id and the server serializes all state data, saving it on the server side, and associates this data with that id. For each subsequent HTTP request by the client, the client sends the session id to the server, which then finds the serialized data. The server can not trust anything that the client sends, so the server needs a way to verify the id. At a minimum, an associative container of some sort is needed that maps the session id (token) to the serialized data. To safely use an iterator or a pointer to the inserted element, the server would need a separate map from tokens to iterators. The tokenmap solution combines the two maps that would be involved (token to session data and token to iterator into the other map, with the token-to-iterator map being extremely fast in performing lookups).
How is it different from having an iterator or a pointer to the inserted element?