TL;DR: make sure you consider the advantages if you want to convince others to change their stance.
Working on production data in development has numerous downsides:
- Privacy: Leakage of unnecessary data to the developers. However, given the devops movement this may be inevitable because they're also the sysadmins; and often people just don't care as long the number of devs is limited.
- Security: connecting to the production database implies that any hacked developer machine fairly trivially can do really nasty things. Hacks require attack targets, and a fully-loaded workstation with one of those unreliable meatbags in charge adds a lot of surface area. It's bad enough if devs can access source control; but it takes more than a script kiddy to exploit that, and it's not always easy to hide infiltration via the code. By contrast, if you can just access the servers, even an automated hack tool has a good chance of taking control of your server.
- Reliability: Working on the live data is bad for two reasons here: Firstly, you can't experiment with data changes (outside of tricky limited scenarios) which means your code will be less well tested when the dev finishes it. Secondly, bugs can have catastrophic consequences because they can make large-scale changes to the most important bits of data you have.
These three downsides have knock-on effects. Because it's risky, work takes more time and attention, which increases the cost of any development. Your network may need fancier firewalling and routing because you suddenly have these "priviledged" machines you need to secure. External assistence is a little trickier because you can't just give every temp the keys to the kingdom.
However...
The various downsides of working on live databases are fairly obvious. People at your workplace surely realize that working with production data takes care and care costs money - even if they don't focus on it. You may clarify and highlight the dangers, and that might help you - but you're probably not telling them anything particularly new, which makes it hard to make a case. You might want to flesh out how the downsides are realistic risks to the specific business you're doing.
However, if you really want to win this argument, you should focus at least as much on the ADVANTAGES of working with production data. You're going to need to understand why they do this, even unstated gut feelings. In short: my real answer is that I think you're asking the wrong question :-).
Once you understand why they do this, you can make a case why your alternative is sufficient.
I don't know your workplace, but I can take a wild stab at the dark:
- Spagetti data-code: The code depends on the data. E.g. something like an accounting period may be a row in an sql table, and without a valid accounting period, (and a valid user, and a valid sales item, and a valid sales rep...) you can't add a bill, which is what you're currently developing. If you've always had production data to play with, it may not be trivial to even run any code without a fairly realistic database because there can be complex interrelated constraints your mock data needs to satisfy.
- Mock data isn't representative: When the problem domain is large and complicated, you mock data is probably not representative of real-world data in some way. This means that code can be less well tested in scenarios that matter. For example, you may have exceptional accounting periods that overlap due to legacy or changes in the legal framework, or just due to old now unresolvable bugs. All those all corner cases are unlikely to be in your mock data once things get complex.
- Mock data is expensive: Creating mock data can be (or seem like) an insurmountable task. If your data model is sufficiently complex, you may need to spend a lot of time creating mock data, and once you're finished, you still need to maintain and update this mock data as code evolves. You've just signed up for even more maintenance duty.
- Conservative mindset: Changing development practices is risky. If it works now, why change and risk making things worse? There's probably dozen of subtle differences you haven't thought of, and any one of those could cost us business. Stick with a proven recipe.
- Learning Curve: Even if the new way is better, it's not worth the investment (and there's always something new in IT, why not pick some other more valuable improvement to make first?)
I bet there are more reasons - but again, I don't know your team. If you want to change their minds, you'll need to consider whatever advantages they think the status quo has, and convincingly demonstrate the new way isn't (much) worse.