Three things I've noticed as a manager of several developers who use or don't use GUI's for git: Pre-commit self code review tends much better with a GUI or at least a good git-aware diff program, leading to higher code quality. Visualization of branches, merges, etc. is much easier with a GUI. Complex merges with conflicts, partial commits, etc. tend to be easier with a GUI like tower.
Being able to do basic things on the command line is definitely nice. And the question is not command line VERSUS a GUI. Tower, e.g. can be used side-by-side with the command line.
However, Tower help you both become more productive and make fewer mistakes. No one likes to inspect a complex project history on the command line. Getting a visual representation of a conflict helps you resolve it more confidently. Automatically having local changes stashed away prevents problems...
There are indeed many scenarios where a GUI is plain helpful - for beginners and pros alike.
I learned git form the command line and it's still my go-to, but sometimes it's nice to have a higher level view of where you are in the repo, both the current commit and tree generally. Especially if I'm working through a big commit or merge, it's nice to see where I am in conflict resolution, etc.
I don't see $60 of value over a few customized git aliases. The 'easy visualizations' in a GUI can be just as easily teased out with .gitconfig snippets:
git add -p, although its main problem is that you can only select chunks, not separate lines. Actually I see that Tower has that same issue. IIRC Github for Mac allows you to select individual lines, even in the same chunk.
Sure. I like SourceTree's git-flow support when I've worked on projects that used it. Most of the time I use Gitbox, which is super simple and fast and nicely integrates with Kaleidoscope.