Git has the concepts it has because they're all important. It shows them all to unfiltered because to do so is vital.
I think the difference is that I didn't start with the official documentation. I watched a video of an introductory talk given by a local Linux kernel developer. The talk started with an explanation of the underlying data model, and then showed how each command manipulates the underlying data structure and how that's useful for version control.
The talk is a bit long and a bit dry, but to date, it's the best introduction to git that I've ever seen. I highly recommend it:
I'm using git (well, forced to, in fact) since 2009 and I've learned its' guts. And I still can't see why should I care of .git contents unless I'm git developer.
Ask yourself this: how come mercurial/bzr/fossil/veracity users aren't aware of those DVCS' internals?
All DVCS systems involve creating and editing a series of changes to a directory tree, including metadata about each change. Those changes and their metadata are basically just a shared document that you're collaborating on with other people.
On other words, the revision history is a document that you're trying to edit. Git's document format it a bit like HTML: you can edit it blindly using a WYSIWYG editor, but it's going to seem confusing unless you at least understand concepts like elements, attributes, and entities, and maybe some CSS. Those concepts map directly to the HTML wire format, so in practice, you'll end up learning that, too.
Mercurial and bzr (I can't speak about fossil and veracity, since I haven't used them) are more like Flash or MS Word: They're easier to use for beginners, but they're more fragile and their internal formats are more obscure.
Check out various short descriptions of push command:
* git — "Update remote refs along with associated objects"
* mercurial — "push changes to the specified destination"
* bzr — "Update a mirror of this branch"
* veracity — "Push committed changes to another repository instance"
* fossil — "Push changes in the local repository over into a remote repository"
As you may want to see, all of them except first one, are easily readable even by person used some VCS before. But not git — to understand what push command does, you have to have gitglossary opened in front of you.
> All DVCS systems involve creating and editing a series of changes to a directory tree
git is not — it stores only snapshots and changes are calculated every time you want to see them.
> the revision history is a document that you're trying to edit.
It is revision history, not "a document". To be precise, in DVCS it is directed (except darcs) acyclic graph, aka DAG of source code revisions.
> Those concepts map directly to the HTML wire format, so in practice, you'll end up learning that
One and only VCS (of 7 I have used) I've ended up learning guts was Git.
> They're easier to use for beginners, but they're more fragile and their internal formats are more obscure.
Which way are they fragile exactly? Could you please back this statement up with some examples?
And why one should care about VCS internals unless he's VCS (plugin) developer?
That's really only true if you're a beginner and you weren't properly taught how git actually works. Fundamentally, git's data model is really simple and transparent. The commands are somewhat arbitrary, but no moreso than Vim's or Emacs's. As with Vim and Emacs, you don't need to know most of the commands anyway, except for convenience.