That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.

The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection.

This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work.

Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example:

  set -e
  git init g
  cd g
  echo 1 >foo
  git add foo
  git commit -m test
  cd ..
  sh git-new-workdir g g2
  cd g2
  git checkout -b foo
  echo 2 >foo
  git commit -a -m foo
  git branch -d master
  cd ../g
  echo 3 >foo
  git commit -a -m master
  git log --graph --all

The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants.

There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.