No offense, but seems your problems coming your unwillingness to learn git properly. If you would take the time and learn it (reading Pro Git book, learning from visual tools, which there are a ton, etc) (Again, no offense, just suggestion.)

> Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things.

You don't need to know all 148 of them. If you only know 16 (1/9 of them): add, branch, checkout, commit, config, fetch, log, pull, push, rebase, reflog, remote, reset, show, stash, status, You can do pretty complex things already. For day-to-day usage, these are more than enough.

> git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system.

Git rebase enables very simple workflows, like the GitHub workflow[1], which IMO is quite simple, small overhead workflow, pretty useful and scalable.
Git rebase is also for local repo only. In every tutorial and even git command recommends against pushing rebased branches to an already pushed remote repository. If you keep this in mind, it makes sense.

> ... to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, ...

I think the reason is not that they want to hide their mistakes, but to clean the history. Would you rather see typos in a history? IMO it's just cruft, an amend or rebase pretty much just a clean up you can read it more easily, and you don't have to deal meaningless 'Fixed a typo' comments...

> There are numerous commands to do similar, overlapping but nonetheless different tasks. If for example you want to back up to earlier versions of code you can do git revert, git reset --hard, git reset --soft, git checkout -- <SHA>, git checkout <SHA> -- all of which do different but overlapping things.

git revert is not the same as git reset. git revert creates a new commit on top of the commit you want to revert. git reset move the HEAD. Totally different operations.
git reset --hard, --soft, etc does the same thing, just differ how they handle the index and working tree, and once you understand I think it makes sense.

> A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches, making locating changes and reconstructing the history of changes extremely difficult.

If you stick to a simple workflow and rebase constantly, this is not a problem at all. Not everybody needs git-flow[2]. If you work on the same files with somebody, I think this will always be a problem, no matter what VCS you use, but with git there are a couple of merging strategies which can facilitate the process.

> Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files as well as snapshots of the entire project.

The SHA1s are for security. A commit's SHA is actually the SHA1 of that snapshot, so if you change any bit of that snapshot manually, git will complain about it[3]. It is basically that nobody can change code unnoticed!

> Lack of backward compatibility with RCS-style version control systems like Subversion.

I don't really understand what you mean here, but there is the command git svn, which is perfectly compatible with SVN. Recently I converted a whole SVN repository to Git without even losing one commit or message or anything...
Also Git supports many more workflows[4], not just centralized.

> ... many obvious problems with Git.

Of course git is not perfect, but instead of ranting about it, you could learn it in a couple of days and work with it, becase many of us think it's pretty flexible and as simple as you want it to be. Actually, if you learn only two commands: add and commit, you can use Git, nobody stops you doing that if you find the other parts difficult.

[1]: https://guides.github.com/introduction/flow/index.html

[2]: http://nvie.com/posts/a-successful-git-branching-model/

[3]: http://youtu.be/4XpnKHJAok8?t=56m20s

[4]: https://www.atlassian.com/git/workflows#!workflow-centralize...