I don't mean to be rude, but you clearly don't understand this subject. Databases leak, not least of all due to human errors. Half the effort in computer security goes to preventing the leaks, and the other half goes to mitigating the consequences of such leaks. Hashing the passwords, salting the hashes, the entire md5/sha/pbkdf/bcrypt/scrypt debacle, all of these things are there only to mitigate the consequences of a database leak that is presumed to happen at some time in the future.

No, not at all. There are many scenarios in which data can be accessed read-only such as ACL misconfiguration, poorly secured backups, 0-day attacks which allow stealing cryptographic keys, overly verbose exception messages, etc.

An adversary who makes a single copy of your database could impersonate any user, and go unnoticed for potentially a huge period of time unless you have good intrusion protection. A targeted attack might steal just a single token, and could last a few seconds only, but then have unauthorised access indefinitely via the token.

EDIT: Incidentally this is why only the hash of the token should be stored in the database, just like storing passwords. Also the token should expire.