In a sense, the index is an acknowledgment of the fact that the operation of "creating a commit" should be a two-phase process, similar to a database transaction.
Phase 1: Choose which parts of the working directory changes should be in the upcoming commit.
Phase 2: Actually commit those changes.
The separation is not entirely clean in Git. While this is very appreciated for convenience (e.g. git commit -a), it blurs the line and does cause confusion.
Indeed, the ability to work on code now and think about a commit later is freeing. As for the particular abstraction of how to represent the commit in progress... I like the working tree for that, rather than the index. It's just a better mental fit for me to unstage stuff I don't want to commit (via shelve/stash), _rerun unit tests_, do a simple diff without needing to remember the incantation for seeing what's in the index, and commit.
Phase 1: Choose which parts of the working directory changes should be in the upcoming commit.
Phase 2: Actually commit those changes.
The separation is not entirely clean in Git. While this is very appreciated for convenience (e.g. git commit -a), it blurs the line and does cause confusion.