I would say it is both a useful tool, and complicated to the point of getting in the way of getting things done
Git has a data model which I imagine is based on the idea of distributed filesystems. On top of that you have something you don't normally get in a filesystem - you save all historical state, and you comment on what a change in state represents.
Beyond normal SCM functions, this model gives you the ability to do all sorts of fun/crazy things:
- Rewrite historical state to obliterate any record of a certain file
- Rebase your filesystem's state based on changes you've seen from other nodes
- Filter the filesystem to represent the contents differently, for instance only represent a single subdirectory
- Create alternate systems for resolving changes from distributed nodes
- Create alternate formats and distribution mechanisms for representing changes in filesystem state, and workflows for manual or automatic application
- Create a union filesystem representing data outside the distributed filesystem
So its not just that git core is complicated - a lot of the wacky tools are actually built into git, and a lot more are available elsewhere. And there are legitimate reasons to want to do some of the more complicated tasks. Since these tasks are useful but not vital, they wind up being tools in a very complex toolbox.
On top of that, you have problems when trying to teach more than command-line formulas or GUI buttons to get certain tasks done - explaining the full model overwhelms new users. But the porcelain is barely decoration, as the git plumbing underneath is exposed in things like command help.
Going beyond formulas requires not just learning, but some torsional force on one's brain so it may reorient inside your head - you have to learn not just commands, but new ideas. But until you do that, even the commands you use as part of your formulas will have help pages that might as well be written in klingon, because they are written in terms of concepts that you don't understand.