I use it for exactly one purpose: authorizing the "ghosting" of a customer account. ("Log in as this user.") Putting that behind SSH means that anyone authorizing a ghosting has both a blessed SSH key and the password to it. Even rooting my session on our admin app, via reflected XSS or stealing my unlocked laptop out of my hands, doesn't get you that. (Our admin app, by design, is less-than-all-powerful. A malicious admin session could do a heck of a lot of damage to our business but, critically, would be unable to access personally identifying data about customers' clients.)
ssh foo.example.com #uses private/public key per conf file
irb > u = User.find_by_email "firstname.lastname@example.org"
irb > u.authorize_ghosting! "Reason for log goes here."
* you'll want to incognito mode the URL returned here*
irb > exit
This is something I would wrap a simple CLI around, and then kick myself in the tukhus for having ever used the language's interactive client to make raw database queries and edits on the production server.
> DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden
You can run raw DB queries against read-only credentials.