in fact I just learned that it's only compared to the index...which explains why I am wondering from time to time why I didn't see that particular difference, now I know.

Like Leonardo said it's the logical thing to do.
A Working Tree is a working tree and not the index.
The object I see is the one to operate on.

It's an everyday use case.

For example:
Someone has committed something which should really be two or even more commits.
This may be lazyness, or working on several things at once, or correcting spelling or translation errors while working on something.
Now I want to import only a certain part of it (lets say I'm working on other spelling errors or translation).
It's easily done for a single file, just do "Compare with Working Tree" (as Thomas keeps mentioning).
But if the changes are distributed over several files, I am not even able to find these.
It's only possible by first staging my own changes. But I may already have staged something while the rest should be kept unstaged.
I could stash my changes, but I may have done a similar change.

Which is the next use case.
I have changes and some incoming branch has also changes in the same area.
Now I want to see, if I have to bother with conflicts with these changes or if I can borrow something to ease the merge.
All before the more expensive operations.
It's simply more convenient to do it live than to start committing my changes, then do a compare and then split or something to get it together. Most operations don't like local changes. Stash etc. all lead to conflict situations.
Directly comparing with and editing the working tree is a lean operation like a shortcut. And the natural thing to do.

Well, it's often used in teams that are very cooperative.
In fact sometimes a co-developer at the other end of the world says, look at this, could it be useful to you (knowing what I am working at)?

At the end, if it's useful for one file, it's also useful for a whole commit.

I am assuming a clean repo, without local changes, which might complicate things too much.
At least in that case, I tend to ignore, if a branch is checked out or not.
Basically, if not, I do the stupid work for the computer not vice versa as it should be :-)
It's the same with cherry picks, why not drop a commit onto a commit that is not checked out for a cherry pick?

thanks, I didn't know the Ctrl-P, that's nice