Let's start with the definition of a tracked file, which is remarkably simple: A tracked file is a file that is in Git's index. Such a file has a name, e.g., path/to/file.ext. Note that there is no such thing as a directory or folder here, it's just a long name with forward slashes—always forward slashes even if the host OS (Windows) is going to call this path\to\file.ext.
The simple answer, then, lies in observing that Git is going to write path/to/file.ext out to your working tree because path/to/file.ext is in Git's index and git reset --hard therefore needs to write path\to\file.ext (Windows) or path/to/file.ext (other OSes). In order to do this, path must be a directory (AKA folder), and path/to or path\to—whichever will be used—must also be a folder.
So, if there's an existing file named path or path/to, Git will remove this file (there's only one, because these OSes say that some path name identifies either a file or a folder—or, at least on Unix-like systems, special items like fifos and devices and sockets, but either way it's in the way). And that's the simple answer to the question about what the phrase you quoted means.
But wait, there's more
There's an issue here. Git's index is separate from Git's commits, and git reset with --mixed or --hard is going to fill in Git's index from the commit you pick:
git reset --mixed a123456
tells Git to look up commit a123456 (by hash ID in this case; you could equally say git reset --mixed origin/zorg to use remote-tracking name origin/zorg to find the hash ID first).
Having found commit a123456 (or whatever hash ID you've specified), Git must now:
- remove, from its index, any files that aren't in
a123456;
- add, to its index, any files that are in
a123456.
These "remove" and "add" steps may involve touching the working tree.
If we use git reset --soft, we tell Git don't touch index or working tree at all, so that only the first step, moving the branch whose name is stored in HEAD, occurs. If we use git reset --mixed, we tell Git don't touch the working tree at all, so that only the branch-move and index-resetting occur. But when we use --hard, the working tree must be updated.
The "remove a file from the index" part of this update will also remove the corresponding file from the working tree.
To observe this happening, start by creating a file in the working tree, leaving it untracked as you did:
echo data > some-file
Running git status will show it as untracked (?? some-file in git status -s output, for instance). As you already saw, git reset --hard won't change this.
Now copy the file into Git's index using:
git add some-file
Now git status will show this as a new file to be committed. It's not in the current (HEAD) commit, so the diff from HEAD commit to index / staging-area shows some-file as new. It is in both Git's index and your working tree, so the diff from index to working-tree shows nothing.
Now run:
git reset --hard
which resets to the current commit. This makes Git rip the file some-file out of its index, because a file named some-file is in Git's index right now, but it is not in the (newly-chosen) HEAD commit (which "accidentally on purpose" "just happens" to be the same as the previous HEAD commit, since we didn't pick some other commit to move to). And we used --hard while we did this, so that made Git remove both files.
Now repeat the exercise, but use git reset --mixed first, then git reset --hard. Try to predict the effect.
Finally, repeat the exercise, but before git reset --hard, run git rm --cached some-file.
See also ElpieKay's example of a file that is in the current commit, is not in Git's index at the moment, and is untracked in the working tree. I forgot to cover this case above, but it falls out of the same complications.
