Why does extracting a specific git tag to a /tmp directory mess up the working tree?

It doesn't (do anything to your current working tree). What it does effectively damage / mess-up is the (singular) index. (It also will affect HEAD.)

Each non-bare Git repository has one working tree, one index, and one HEAD. That one index is used by git checkout or git switch; that one HEAD is set by it. When you run:

git --work-tree=<path> checkout ...

your Git extracts the specified commit—the ... part—and writes it through the index into the working tree.

Normally, the working tree to which your git checkout or git switch would write is the (singular) working tree. But with --work-tree you temporarily override that one working tree with one different working tree—so that is the working tree to which this Git operation writes. But you have not changed the (singular) index, nor the (singular) HEAD, and git checkout or git switch will write to those as well.

The HEAD keeps track of the current commit by containing:

• a raw hash ID, or
• the name of the current branch (with the branch name itself then containing the commit hash ID).

The index holds your proposed next commit, which starts out matching the current commit—so that when you switch commits, Git first removes the existing checked-out commit's files (as recorded in the index and stored in the existing in the working tree), and then plugs in the target commit's files (to the index and working tree). Using --work-tree to re-point the working tree, without first cleaning out and removing the current working tree and index, leaves them out of sync.

If you don't mind the effect on HEAD, and are otherwise using this git checkout or git switch for a special purpose, consider setting GIT_INDEX_FILE to the name of a temporary file that does not exist now, and that you will delete once the git checkout or git switch finishes.

If you do mind the effect on HEAD, or intend to do this for more general purposes, consider not using git --work-tree checkout like this at all: instead, make sure your Git is at least 2.15, and begin using git worktree. See the git worktree documentation for more about git worktree. Edit: Or, as jthill notes, use git archive to build an archive you can extract without disturbing the working tree (note that this is a bit different, especially if there are .gitattributes rules for archive-building in the tag you'll be extracting).

This is only a partial answer. I don't know why the working directory gets messed up when extracting to an unrelated directory, but it's possible to return to a sane state—the one where the repo was just before the git --work-tree... command—by running:

git reset --hard HEAD

What you wanted to do was either

git archive v2.1 | tar Cx /path/to/tmp/tree

or

git worktree add /path/to/tmp/tree v2.1

or

git clone -sb v2.3 . /path/to/tmp/tree

or even

scratch=`mktemp -d`
GIT_INDEX_FILE=$PWD/.git/scratch-index git --work-tree=$scratch read-tree -um v2.1

because as @torek points out git checkout is a convenience command, built for "standard" workflows where your work trees are for content you're actively tracking; the index is Git's manifest for what you last checked out or added there, and HEAD is its ancestor commit.