If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.
Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away.
I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one.
I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.
It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.