According to the git rm documentation, this is how it behaves:
Remove files from the index, or from the working tree and the index
If I just did a commit and my index is empty, executing git rm some_file will stage the deletion of some_file. I would expect rm to not do anything. Why is it deleting a nonexistent file and what is the final effect on the repository?
The trick here is that the index isn't empty after a commit.
In fact, it contains exactly what it had before-and-during the commit.
I'm not sure where this notion comes from. It's true that git commit has a flag spelled --allow-empty, which perhaps makes it look like the index would be empty at this point, but it's the spelling of the flag that's misleading: what it allows is an empty diff, rather than an empty commit.
It's also true that git add adds new stuff to the index, but in the case of a file that's already there, the new stuff being added is just displacing the old entry that's already there. (Perhaps the spelling of git add is what leads people to assume that the index is empty after a commit?)
(One other slightly peculiar bit is that git rm also adds something: specifically, a record to say that "this path-name, which does exist in the HEAD commit, should not exist in the next commit." This is because the index plays a dual role: it's not just "what to put in the next commit", but also a cache to speed up git scanning through your work-tree. You can in fact remove the index file entirely, which de-stages everything but doesn't schedule anything for removal: git just re-builds the index from the HEAD commit in this case.)