(Also, tools for software engineers still benefit from clarity and focus of purpose for simple use cases.)
I do too and I believe the problem with git is that it's somewhat usable without grasping even these basic concepts - until the day it isn't, as something goes off the beaten path and you just end up getting lost. It also doesn't really nudge you towards understanding as you keep using it; to the contrary - it happily lets you build some suboptimal mental models that are doomed to stop working at some point.
The only way to learn git well right ahead is to sit down and read. It isn't much to learn, but most people just skip this step and go straight to CLI. I can't blame them, I did the same many years ago, so it took me much longer to actually know what I'm doing than it should as well. But the thing is: I didn't know better back then, nobody told me that. Now you (the reader) know, so you have no excuse :)
In the biotech startup I worked for, the biologists and the chemists absolutely had to deal with the code that we wrote, that was the only way we could get things done! I think maybe in very large organizations with people to spare, and large departments, and official policies, you can have rules like that. But at smaller places, you have to get scrappy and have everybody work with everything. That involves non-engineers using git!