Over on Twitter I said something:

It's funny how "we don't have an equivalent of the git index" is now a DVCS anti-feature for me. I like what the index enables and it has a clear conceptual model, even if it can be sometimes annoying.

(I agree that it's a bad name.)

There are two sides of thinking that Git's index is a good thing. The first is the practical side, where I like what it enables me to do. On the level where all VCSes are user interfaces to mathematics, the operations and double checks that the Git index readily enables are both useful and reassuring. Being sure of what you're going to commit before you do it and having powerful selective commit capabilities are both useful, and they're even better together.

Of course you don't have to have Git's index in order to support these operations. Plenty of other VCSes support partial commits (even committing just parts of files and changes), checking what you're going to commit in advance, and so on. The other side of Git's index is that it provides a clear conceptual model for all of them. By creating a clear separation between 'what is in your working tree' and 'what has been prepared to be committed', Git makes it more straightforward to reason about how various things are going to behave. It also makes things more inspectable; Git's staging area is a real thing with a concrete existence and commands that manipulate and inspect it.

Git's index isn't perfect, apart from the name, and a fully elaborated system could be built with a different conceptual model (for example, you could have a model that commits are built up over time, amended and modified until you freeze them). But having a straightforward conceptual model that cleanly enables the useful user interface features is a valuable thing.