It's generally a bad idea to develop with a copy of your production DB. This is how emails accidentally get sent from staging servers to real people and how sensitive information finds itself in insecure places. I didn't see any part in the tests that deals with scrubbing sensitive data, so to me this is just enough feature to be really dangerous.
Yes, it's a very specific power tool. If you don't want to pull production data or clone it to your staging environment then this is not useful.
I used to work at Amazon where this was a huge deal to us because of credit card numbers, PCI compliance, etc. Still, I believe our staging environments had a copy of prod data. At Open Listings we have pretty good safeguards against mass emailing (mostly this mail interceptor: https://gist.github.com/psugihara/3caa217486f86a848d6abf21d7...) and while we handle some financial docs for proof of funds, we ask users to black out account numbers, etc. No matter what you do though, at least some engineers are always going to have the keys to the kingdom (and since we're 3 engineers, all of us do).
The most common use case (why I use it almost everyday) is for debugging something that went wrong in production. For instance we import listings from several MLS sources every few minutes and merge updates into Property objects in our system. The raw MLS response is saved on the Property object so that we can rerun the update if something changes and we have to update our data mapper. Likewise, if something gets strange with an Offer, I just pull Offer and User collections and can take a look at the actual documents in my rails console without manually touching our prod servers.