You bring up some valid questions - thanks. I think you are getting at a few scenarios where, in fact, perforce is better. I like git, by no means is it the best solution for all cases.
if git is great, is it worth changing an enterprise to use it?
There are a ton of factors involved in answering that question. A lengthy blog post could be made trying to answer that.
when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc.
This depends on how git is setup. In the simple model of everyone on a team having push access to one origin server that serves as, effectively, the central repo, and that repo allows force pushes, then yes, this may not satisfy an auditor. As in, anyone on the team can rewrite history. Of course, when the central repo suddenly doesn't match up with all the copies everyone else has, somebody will probably realize that something is amiss.
That said, being a DVCS, it is not hard to setup something where only a few top level people have push access to the what we'll call the authority server, and all commits from everyone else has to flow through these trusted people. Additionally, force pushing can be disabled on the authority server, so no one person can rewrite history (aside from the people who have direct file system access to the authority server).
Or, think github - people fork a repo, then submit a pull request. Tons of people can commit to a repo, but most commits flow through a trusted few.
how granular and how far back can i get this with GIT?
If you are asking history, the git history goes back to the very first commit. It is also easy to list the entire history of just one file, and more.
how solid is the nonrepudiation factor with GIT?
As with a couple answers previous, it all depends on how git is deployed in the organization. The answer will vary from none to rather good, depending on the deployment.
for commits - can i see who else might be looking at code? for security
If you've granted access to someone to be able to pull from your repository, then no, you can't see who is looking at what. Anyone with pull access will have access to the entire repo. Want finer grained control here without resorting to multiple repositories? Then git is not the right vcs. This is where something like Perforce will win.
can i protect others from getting the code?
In what way? People who already have some access to the repo? See the above answer. Or Joe Q Public? That is trivial.
--
Basically, the big area where something like Perforce (or even SVN I believe) will win is when you need fine grained control over security. E.g. User A only has access to this subfolder, User B only has access to this other subfolder, etc.