I tend to use Git for deploying production code to the web server. That usually means that somewhere a master Git repository is hosted somewhere accessible over ssh, and the production server serves that cloned repository, while restricting access to .git/ and .gitignore. When I need to update it, I simply pull to the server's repository from the master repository. This has several advantages:


If anything ever goes wrong, it's extremely easy to rollback to an earlier revision - as simple as checking it out.
If any of the source code files are modified, checking it as easy as git status, and if the server's repository has been modified, it will be come obvious the next time I try to pull.
It means there exists one more copy of the source code, in case bad stuff happens.
Updating and rolling back is easy and very fast.


This might have a few problems though:


If for whatever reason web server decides it should serve .git/ directory, all the source code there was and is becomes readable for everyone. Historically, there were some (large) companies who made that mistake. I'm using .htaccess file to restrict access, so I don't think there's any danger at the moment. Perhaps an integration test making sure nobody can read the .git/ folder is in order?
Everyone who accidentally gains read access to the folder also gains access to every past revision of the source code that used to exist. But it shouldn't be much worse than having access to the present version. After all, those revisions are obsolete by definition.


All that said, I believe that using Git for deploying code to production is reasonably safe, and a whole lot easier than rsync, ftp, or just copying it over. What do you think?

I would go as far as considering using git for deployment very good practice. 

The two problems you listed has very little to do with using git for deployment itself. Substitute .git/ for the config file containing database passwords and you have the same problem. If I have read access to your web root, I have read access to whatever is contained in it. This is a server hardening issue that you have to discuss with your system administration. 

git offers some very attractive advantages when it comes to security.


You can enforce a system for deploying to production. I would even configure a post-receive hook to automatically deploy to production whenever a commit to master is made. I am assuming of course, a workflow similar to git flow.
git makes it extremely easy to rollback the code deployed on production to a previous version if a security issue is raised. This can be helpful in blocking access to mission-critical security flaws that you need time to fix properly. 
You can enforce a system where your developers have to sign the commits they make. This can help in tracing who deployed what to production if a deliberate security flaw is  found. 

