1) That database dump of the users table that someone put on a usb drive and lost.
2) A brute-force attack via a misconfiguration which allows remote logins to mysql. No "rails stack" access, but the passwords are now compromised.
3) The non-application backup server with DB dumps.
4) S3 access is compromised and unencrypted dumps to S3 are downloaded.
I guess I could keep going, with the attacks getting more outrageous, but I can assure you that stranger things have happened.
Back in real life: All four of your scenarios give me full access to the users table, right? That should be sufficient for me to run my favorite common passwords dictionary and compromise, hmm, 70% or so of them at my leisure. If I wanted a particular one, for example for the admin account or an email address which looked interesting, I could rainbow table it. If I wanted to be extra clever real name and email address gives me two extra datapoints to run for brute forcing and the opportunity for targeted spearphising, but hey, with successful compromise of most of several million accounts I'll already have my hands full stuffing my pockets with your users' money.
Like most proposed solutions added to stop movie plot threats, this one doesn't even work, but it does take mental bandwidth you could be using to implement security that actually matters. (Look how every always latches on to "you don't salt passwords!" and most ignore "Rails does not escape HTML by default, which puts every Rails site at the mercy of the worst coder remembering to h() all their tainted data.")
Bull.
Back in real life:...
Well, in my real life, I've never "rainbowed" a table, or even know what that is after 12 years in IT, but I sure can open a sql file in a text editor and figure out which field is the password.
It's a layer of defense and widely accepted as the minimum and so easy to implement it's ridiculous to argue against it, especially as a "movie plot threat".
Quick, somebody make a movie out of this: