AFAICT there are only two workflows involving the staging area: staging partial commits and resolving conflicts. The first case is taken care of by partial commit support, and the second case presumably has its own dedicated mechanism.
* get the hash of the HEAD commit * run `git diff <hash>` and see that there are no changes * make some change to a file * run `git diff <hash>` again and see the change you made * stage the change with `git add` * run `git diff <hash>` again and no changes are show! * commit the change * run `git diff <hash>` again and the changes are back
It's super bizarre to me that there would be some sort of intermediate state where changes aren't visible. I feel like it would make more sense to have some sort of formatting difference indicating unstaged versus staged but not committed versus committed, but I imagine changing that now would break all sorts of scripts, so we're stuck with it.
Staging just means "I'm happy with the changes so far but didn't finish everything I want in my commit; let's ignore this changes for now".
What `git diff` does by default becomes useful when you touch the staged changes again. Then you see only the new changes compared to the staged stuff. This helps building up a commit step by step, with some trail and error in between.
Think for example about something like: You use some tool to do some automatic changes. This creates hundreds of changed files. But the result isn't working. You could commit that, sure. But than you would need to rewrite history before pushing because creating not working commits is a terrible idea. Or you could just stage the changes for now. Than you can change / repair the still missing parts. Git diff will helpfully show you only the new changes but ignore the staged stuff as long as it's untouched. You would now for example easily see changes that you made to the automatic rewrites. Without the staging behavior you could only compare with a committed state, and drown in hundreds of changes that are unrelated.
The main problem with the staging area is that quite some GUI tools don't use it correctly. The tools try to "simplify" Git by ignoring how the stating area is supposed to work, or ignore it completely like the infamous JetBrains IDEs. (IDEA is the tool that needed almost 10 years to implement Git sub-modules…). I think the VCS handling in IDEA is on the surface very polished. But when it comes to something like the staging area the UI-wise very crappy VS Code Git support beats that by far. Sublime Merge does also the "right thing"™ and hides the staged changes at the bottom so you see only the the changes to the changes. Exactly as the staging area is meant to be used!
Git is conceptually very sane and logical. But the UX is indeed (still) terrible.
But a lot of people seem to complain about the complexity of the underlying concepts. That makes no sense to me as the concepts are complex because the problem at hand is complex. Also it makes no sense to me that people are constantly crying for a new tool even they have obviously issues with understanding the problem space and all requirements. A new tool would not make all this complexity go away! It could at most try to "hide" some of the complexity by introducing magic. This wouldn't be helpful at all as magic is way worse than bad UX, imho. Bad UX is bad UX you can deal with it. But when magic goes wrong all bets are off and you're usually in deep trouble.
This looks like people would argue to rewrite the back-end (some propose form scratch!) even only the front-end needs some face lift…