Given that nothing stops you from running a centralized Git repo for things that are candidates for audits or release. If someone uses that as their reason for not switching to Git, it indicates to me that they don't understand their requirements and/or is using it as an excuse because they don't have any real reasons.
I'd even argue that if you want more control and auditing, Git is an improvement over alternatives like Subversion, because it makes it more manageable (and so more likely to actually happen) to set up workflows with far more frequent commits and subsequent reviews by a gatekeeper. You don't need to let your lower level developers even have any kind of access to the main repository, yet you can retain full history of changes that happens before their code is approved and pushed to the main repo by a suitably anointed person.
If you're using a gate keeping process, it doesn't matter what the committers even use then. They can just push a patch to the gate keeper.
You sound pretty close-minded and relatively inexperienced if you would turn down a great career because they used something other than git. It's borderline idiotic to make such a large decision based on something inconsequential. Maybe that's okay in the Web app industry where most of the jobs are just variants of the same thing so you have plenty to filter through, but the idea of turning down a job at somewhere you've been hoping to work like NASA or Google just because they don't use a tool you like is one of the dumbest things I've heard in a long time.
"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.
