"Why do you need to control/audit all work done locally rather than what is pushed to your main git repository, and how can you realistically enforce that with any tool?"
In Subversion you can explicitly check out a file so others cannot. That's rather important if you are modifying binary blobs of data with no way of merging conflicting changes. Art assets like video and images are good examples.
Subversion (and Perforce and other centralised tools) will let you restrict who can check out what from a repository. That's useful if you want someone to only work on a small part of the code but cannot risk giving them access to all of it, for security or secrecy reasons.
And finally, as much as I love git and DVCS, for some teams Subversion works just fine. They may well have Continuous Deployment set up with strong CI tests on commit or they use Subversion's "reintegrate branch" functionality which is somewhat similar to rebase. Honestly, merging in Subversion isn't really that bad.
If you can't risk giving someone access to all of it, giving them any kind of access to what in my experience is likely to be a poorly secured centralised repo is a recipe for disaster.
E.g. I've worked on systems that were ostensibly locked down like this. Except that for any developer who cared, getting physical access to any number of machines where the "secret" code would be sitting checked out, with suitable credentials to do stuff to it, was trivial.
I'm sure some people get it right. But I'd be very critical of that as a reason. Especially given that you could easily solve this in Git too, by putting the sensitive stuff in a separate repo.
Your point regarding binary assets is better, and if someone had raised that as an objection to git, it'd be worth listening. But that's a very different argument than the hypothetical argument posed above.
"SVN works for us" is also a very different argument.
Had those arguments been given, I'd be sympathetic. But the hypothetical "we need control and auditability" given above would be a red flag to me.
The binary blob argument is a subset of the central control paradigm. Without the built in notion of having to perform actions against a central server, git makes it very difficult to perform those tasks.
How about the removal of a sensitive file accidentally added to a git repo? It can't be done without rewriting the entire commit history after the file was committed and then forcing a push which will screw everyone up with an existing clone.
You could argue that the file should never have been committed, but then I'd argue you have never worked with humans.
