Git

That's a lot of words. I think the reasons are pretty simple:

1. Some people just don't care.
2. The Git CLI is poorly designed e.g. the many different ways to delete something.
3. Some Git concepts are very poorly named, e.g. the "index", "ours/theirs". This adds to the confusion.
4. There are many Git GUIs but only a very small number of actually decent ones (if you're wondering: GitX, SourceGit, Git Extensions, and the Git Graph VSCode extension).
5. There are a lot of idiots out there telling people not to use Git GUIs, when they are clearly the best way to learn how to use Git. Its easy to get into a mess if you can't see what you're doing.
6. Git isn't actually as simple as us pros would like to think. The underlying model and even the implementation isn't too complex (I've written a Git client form scratch; not too hard apart from the lack of specs/docs). But you can easily get into a state where you're pulling from a remote and someone else has pushed to the same branch so you need to resolve that (oh btw don't do what Git tells you to!), and maybe it involves submodules too, and you basically need to fully understand Git's model and be pretty good at the awful CLI too to resolve it.

Very good article for folks who've had to teach juniors/trainees Git before.

This is, to my mind, one of the greatest advantages of git (and, by-the-by, also automated testing): the added security that being able to restore to an earlier state whenever you need to allows you to take more risks and try more things when building software.

Yeah, I always tell them it's like checkpoints or like a save in a game.

But this also ties into the needing-a-teacher aspect to properly learn Git: Due to the nature of what Git accomplishes, it has a lot of complex failure modes. And at the start, you need a teacher to get you through those.

The worst-case is if they start dreading merges, because they can't past them and then they try to merge less often, which makes the conflicts so much harder to deal with.
Or if they can't get past merge conflicts and stop seeing the point in small Git commits and in good commit messages. That also makes merge conflicts so much worse.

That's kind of my motivation to be good at Git. I need to be able to tell juniors, that if they've created a commit, then we can unfuck the repo no matter what they might do wrong.

I don't agree that Git has a "steep learning curve". you can literally pick up the basics for what an average dev actually needs in like 5 minutes. made a change? commit it. didn't work? ok diff it or whatever or just go back to the working version. everything good? cool push it. done. That's pretty much what most people just use it for. Is this the proper way? no it's not but honestly who cares? I highly doubt Linus even cares or thinks about how people use or don't use Git. By his own admission Git is just an afterthought for him, just a simple tool he needed for Linux and then handed it off to another maintainer at the first possible opportunity.

So no I don't believe we need extensive courses or even an alternative "easier to use" Git. It's a tool that can be learned in 5min for the basics of which the basics is all the majority of devs actually need.

It's why standards like conventional commits helps a long way in the workplace

Well it all starts at the very own git developers, since they don't know how git should function, then how to expect anyone else to understand.
E. g. I just turned it in to somewhat functional svn with bunch of git aliases and cope with that.