Depends on how many features you want it to have, and what level of control over it you want to have, I suppose. It's hardly unique in being a tool one needs training to master. How many programming language books are there? Database theory books? Adobe Photoshop guides? Safety instruction guides for power tools? Best practices for building construction... You have to learn a thing to use a thing. Git is no different.

Your argument seems to be that git, like all change control systems, is powerful and requires explanation. I would counter that there are other change management systems I can explain in 5 minutes, such as Perforce. Git is hard to explain because its model is a mess and few or no people naturally grok the model right away.

While nothing is perfect, I think Git's model is extremely intuitive and easy to work with. Perforce is centralized, isn't it? That's a deal-killer for me. I think we'll just have to agree to disagree, which is perfectly fine :-)

In my professional experience the distributed nature of git isn't used. Individual engineers don't distribute patches or pull branches amongst themselves, there's always still a central repository that is "the repo". Compliance audits of code and build artifacts in the business world pretty much dictates this model.

I think the fact that you can use git locally to work within your perforce workspaces indicates some commonality among the two models, but git has way more features, edge cases, and jargon.