I would like to refer you to this blog entry by Joel Spolsky.
The reason you're seeing for these junior developers picking it up quickly is very likely because they do not have a predetermined notion regarding how version control in general works, or at least not an as deeply ingrained mental model of it. As such they come in with a clean slate. Your more senior programmers are likely trying to apply the concepts they already know, and are failing as a result of that.
In addition to this, as much as I don't like saying it; who actually reads user manuals? Typically they are very bad at explaining basic usage. Just look at the git commit page from the manual and consider how many new terms and phrases are being introduced to someone who isn't up to speed with the concept. Without a good introduction I'd likely have given up on using Git right there and then.
My personal advice would be to start explaining the commands:
- git add < files >
- git commit
- git pull
- git push
Logically merge conflicts should be explained next, because that's definitely going to be your first issue once people learn how to commit code.
Typically situations will arise where people will need to invest more time into learning stuff (reverts, tags, merge conflicts, branches, rebasing, hooks) but trying to explain all of this before it's needed will not help the people who are having trouble getting into the flow.
Just to wrap it up: From my personal experience some people simply don't spend that much time exploring new techniques, concepts or tools and they typically tend to pick up things you introduce them to at a slower pace. This does not mean they are bad programmers or bad people, but they typically have a narrower skill set.