I think most people just have the 5-6 obscure/painful commands they execute more than once a year stuck in an alias, and don't have a strong enough need for Yet Another Thing to Install on fresh systems.
It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"
After having worked with people that were absolutely hell bent on never using the CLI version of git (and having helped them fix the screwups of their GUI tools a good number of times), I actually think most people would be better off trying to understand how git works internally a little bit more instead of just installing another tool after the last one disappointed them.
I don't say you'll have to be an expert, but not having a clue what the tool actually tries to do doesn't really help in those cases (neither does it if you want to do something complicated in SVN, for example) - and the abstractions GUIs add on top of git are bound to break sometime.
That is - of course - if you are using git in more than just some basic way. If you're the single person committing code, it will "work" anyway.
Perhaps that's the problem: Some people don't see that collaborating on the same set of files in more usable, but also more complex ways (than they are used to) requires more orchestration than just "lock - update - release"...
It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"