I am for having the right data in the right environment.

Dev databases should have a data set that is representative of Production but smaller. All known scenarios should be covered. This includes having some bad data in Dev if the Prod system can allow it to get in there. You won't always know what these scenarios are until you run into them in Prod but when you do, just add the scenario to the test data set. The point of the Dev environment is to provide developers with enough data to test their stuff without hindering productivity. Security hinders productivity so there should be no sensitive data in Dev.

So, how do we test properly against the full data set to verify performance and quality. I argue that it's not the developers' job to do this. It belongs in the hands of the Quality Assurance (QA) team. The QA team should be testing on their own set of servers with their own data. This would be a smaller group of people so testing against Prod data shouldn't be as big of an issue. If it is an issue then you need to use test data here but they should be comparable to Prod in size as well as data distribution. The QA environment is also a good place to do regression testing. Go ahead and set up all your nightly jobs and unit tests to run against QA as well as Prod. That should help you discover those unknown scenarios in your new code before it gets to Prod.