Documentation: completely invalid. The man pages might seem a little terse, but then if you are looking up a command and you don't understand the terminology, then you should probably consider typing in...
I think a cardinal virtue of documentation is to but info where people expect to find it. Saying "Oh, you read the MANUAL. When I said RTFM, I mean the MANUAL for the TUTORIAL" isn't much of a help. If the documentation isn't where novices expect to find it, it doesn't exist.
Unsafe version control
DON'T DO THOSE THINGS!
How many can be done by accident? Are you using revision control at least in part for the ability to recover from a stupid accident? The fact that it isn't safe means you can't count on it being safe. You can't use it as essentially a way to have real point in time recovery for your repo, and it also means you can't count on it being an audit trail because at a minimum it could bet wiped out. That's fine, but it's worth stating up front that this is something Git doesn't do very well. Fine. Understand it is a tradeoff.
Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done.
forcefully pushing things to remote repositories can be denied with hooks, so if you really do not trust the people with push access you can use that. For anything else, it's pretty much always possible to undo any damage by using the reflog.
In my experience, git is the least unsafe VCS I've used. if I commit a file, I know it's safe from accidental removals (as long as I don't touch .git). If I push the commit to a remote (private or public. Could even be on the same machine), it's safe from anything I do locally. So if I am going to do a complicated merge or a rebase, I first make a temporary commit to save the state of the repository and ensure that I can always undo any mistakes. You can't always do that in svn, since commits are immediately public.
Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done.
Or more likely not knowing what you are doing, getting disoriented and combining the wrong options.
I haven't been using git for that long but I could totally see myself getting confused and typing something like that in by accident.
Even then, you can get back to something sane by using the reflog: master@{yesterday} refers to the master branch as it was 24 hours ago, and you can view the different things you've done to HEAD by just running `git reflog`. It's really really hard to blow away the reflog without meaning to -- you're much more likely to just `rm -r` the whole repository by mistake.
The documentation is, in fact, in a place where novices can find it. There's a man page with tutorial information.
What I find amusing is the paucity of information you find in man svn. Try it, you might be a little surprised! Though I have to admit, svn's inbuilt help is quite good.
With regards to not doing the things that can destroy data, in actual fact (as has been pointed out below) there is only really one thing that can't be backed out of is git gc, everything else can be recovered from the git reflog.
As for git having an "audit trail", it has never claimed this.
I think a cardinal virtue of documentation is to but info where people expect to find it. Saying "Oh, you read the MANUAL. When I said RTFM, I mean the MANUAL for the TUTORIAL" isn't much of a help. If the documentation isn't where novices expect to find it, it doesn't exist.
Unsafe version control
DON'T DO THOSE THINGS!
How many can be done by accident? Are you using revision control at least in part for the ability to recover from a stupid accident? The fact that it isn't safe means you can't count on it being safe. You can't use it as essentially a way to have real point in time recovery for your repo, and it also means you can't count on it being an audit trail because at a minimum it could bet wiped out. That's fine, but it's worth stating up front that this is something Git doesn't do very well. Fine. Understand it is a tradeoff.