You can't just blindly run git commands without being aware of current state. Some beginners or people with less technical roles try to use git by blindly running 3 commands they memorized, but that easily results in a mess or situation where it's necessary to call a more experienced colleague to fix their local copy.
For me one of the biggest benefits of using a git GUI is always visible current state: what you have checked out, what are the recent commit, what's the state of other branches, do i have any unmodified files. All of it in front of my eyes, not requiring any additional input (beside alt tab for switching to the graphical git client). Not that you couldn't get the same information from git CLI, but the question is how often would you do that, and would you check all of it each time.
But I often perform many of the actual changes in terminal using the default git CLI client.
In this sense I consider shell integration based version control clients bad, as they require using context menu to open the information windows and it's a step that can be skipped since most of the other actions will likely be in the same context menu. Thus you endup with similar situation as CLI clients - information is available but you have to actively request it.
Next step to consider is TUI vs GUI. I find that that often due to constraints of fixed character grid and limited graphical elements TUI can be less dense. Every box and separator line means a wasted row/column. Two boxes side by side - that's two wasted rows. Everything being monospace font - additional wasted space. Single font size for everything - makes it impossible to use smaller size font for short less important text. You can set a very small text size in terminal, but it hurts overall readability of the TUI and all other work you do in terminal, and it doesn't change the fact that TUI was designed with limited available space in mind thus you only get slightly longer text but no additional information.
On the other hand TUI will more likely have a very efficient keyboard only navigation and single key actions. GitUI and many Norton commander inspired TUI file managers like FAR and MC are good examples of this.
For me one of the biggest benefits of using a git GUI is always visible current state: what you have checked out, what are the recent commit, what's the state of other branches, do i have any unmodified files. All of it in front of my eyes, not requiring any additional input (beside alt tab for switching to the graphical git client). Not that you couldn't get the same information from git CLI, but the question is how often would you do that, and would you check all of it each time.
But I often perform many of the actual changes in terminal using the default git CLI client.
In this sense I consider shell integration based version control clients bad, as they require using context menu to open the information windows and it's a step that can be skipped since most of the other actions will likely be in the same context menu. Thus you endup with similar situation as CLI clients - information is available but you have to actively request it.
Next step to consider is TUI vs GUI. I find that that often due to constraints of fixed character grid and limited graphical elements TUI can be less dense. Every box and separator line means a wasted row/column. Two boxes side by side - that's two wasted rows. Everything being monospace font - additional wasted space. Single font size for everything - makes it impossible to use smaller size font for short less important text. You can set a very small text size in terminal, but it hurts overall readability of the TUI and all other work you do in terminal, and it doesn't change the fact that TUI was designed with limited available space in mind thus you only get slightly longer text but no additional information. On the other hand TUI will more likely have a very efficient keyboard only navigation and single key actions. GitUI and many Norton commander inspired TUI file managers like FAR and MC are good examples of this.