NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first.

Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic.

Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.

The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history.

For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.

I've been using magit for almost a decade now and it directly contradicts what you're saying simply by existing and being as awesome as it is

I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog?

With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.