With salt the id's won't look the same in the database, even if they are.
For the foreseeable future, a 72-bit random token will be globally unique, so Salt is not necessary.
Pro [to hashing] The attacker can't read the [plain session token] to send directly.
- It is best to check for a matching IP address in addition to session token. This may not work for mobile users because if their IP changes (i.e. weak signal) then they would be signed out.
Otherwise the attacker can use the session token from any IP, which, as you suggest, (after an SQLi attack) is little more than a convenience, because the attacker already has access to the full database.
However, hijacking a session in this way would be quite useful if some files/data are stored outside the database. (and if the compromised sessions have access to see that data)
[The session token] is not really a secret that leaks to other sites, like passwords would.
If the database is compromised, all data is readable anyways. No need [for the attacker] to take the API way.
Sometimes files or data are stored outside the database.
A fairly common security procedure is to use separate database user accounts, so it is possible that the session tokens could be stolen with a read-only SQLi (i.e. limited access database user), with the most sensitive data remaining secure (i.e. requires special purpose database user)
You may want to use passwords (and session tokens) to access encryption keys down the road.
It's really easy to run a quick SHA-2 on the session token, so if there's any chance that either #1, #2 or #3 will be implemented down the road, then go for it!