I think there are two things being conflated here.
One is: how do you effectively manage changes to a codebase over time? Git has a model that, for day-to-day use, has primitives like "commit", "branch", and "tag". You also have to understand the difference between your working copy, what is staged for commit, and any other commit in history. These, in combination with the operations you can do with them is actually somewhat complex. This is the thing I am saying people need to learn. And people quite often complain about it.
The other is the organization of git's porcelain layer, the arguments and flags each subcommand takes, and how stuff is presented back to the user. I think git stands to make significant improvement here. Be that as it may, the tool exists as it is. So your options are to use a different VCS entirely, use a different frontend, or learn how to use git as-is.
If you choose to use git but deliberately avoid learning e.g. what a rebase is and why it's useful, you are choosing to be an ineffective developer. Could it be better in some ways? Yes, but it isn't.
I don't think the car analogy is particularly compelling. The "primitives" of a car are already much simpler than git's. The fundamental primitives of a car are "go faster" and "go slower", along with some supporting things like managing your headlights, windshield defrosting, wipers, and horn.
While additional tools are being added to cars to make them safer (e.g. a backup cam or collision detection), the complexity of those tools is increasing rapidly which makes them more prone to failure. And a driver is absolutely not excused from causing an accident just because one of these safety tools failed. You still have to know how to safely operate your vehicle in a variety of conditions.