One caveat comes to mind about the approach this technique supports. Anonymizing your production data and distributing it to developer laptops is something you should think hard about before doing it, and approach very carefully if you do. Sometimes the sensitive information you should be protecting isn't just the users' creds and addresses. Sometimes it's the ways in which they've used your app, the content they've created, and the graph of other accounts with whom they've associated.

A typical anonymized DB dump is likely to share primary key values with production, and often an adversary knowing that user X posted something they'd rather keep private on your app will be able to simply look up their identity on your production server without privileged access.

Generating useful fake data is also hard, of course, and won't hit your edge cases like real production data, but then again, the code you're writing now won't really be exercised by the unwashed masses until you release it, so using production data is mostly a protection against regressions. If you've got sensitive content in your app, you should consider stronger test coverage in lieu of production dumps. Of course performance regressions can be hard to keep under wraps with automated testing (though you can defend against things like N+1 query problems), so YMMV.