Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.
There are a significant number of ways paswords/password hashes stored in a DB might be revealed that wouldn't result in write access to the DB.
Off the top of my head:
(1) Timing attacks against string comparison (in the hash cases, this usually also implies a guessable salt)
(2) Misconfigured servers showing exceptions/debug info to users, coupled with sensitive information in debug messages, coupled with a remotely triggerable exception
(3) Compromise only of the offsite backup site containing DB dumps but no access to the live DB
(4) Flaky drive is replaced without being physically destroyed. Dumpster diver gets drive working again briefly and gets partial/all DB contents at drive failure time.
(5) Someone else compromises the DB and posts a dump on the web.
A big part of good security is taking steps to keep small errors from being leveraged into big problems. (Though, I'm not saying that read-only access is only a little problem.)
Account read-write access opens up a lot more opportunities for fraud and abuse vs. account read-only access.
Your comment is killing the layout of this page. Can you please fix the formatting of your message? HN does not support arbitrary markdown. And even if it did indenting by four spaces would yield pre-formatting not an ordered list.
SQL Injection is an application layer exploit that gains the attacker access to the database, but does not involve any sort of privilege escalation. Consider this: an attack gain access to your bank's user credentials database. Do you want them to have access to your unencrypted password? Is it really so "harmless"?
