Worktrees are a different way of managing multiple branches in flight. They're not hard to use, and using them doesn't imply any incompetency with git. They are likely being used to cope with another kind of problem.
Why would you ever have build artifacts, incremental or not, as part of your code repo?
Instead of stashing or anything like that we would commit with the text "WIP". Every time we had a stable point, we would make a "WIP" commit and then continue, giving us a good point to revert to if the next steps don't work.
If someone interrupts me I would make a WIP commit and then revert it and then make the change they're asking about.
Later on we would squash the WIP commits and make real commits out of the changes.
Another nice thing about this workflow is that everything goes into the reflog.
Just one concept instead of (1) commits (2) stash (3) oh these changes, eh, I don’t know what to do with them... let’s think about it after lunch.
Here's one example:
I'm working on a trunk-based project, and I am upgrading a core framework like Angular or Django. That's a fairly intrusive change that involves modifying some untracked on-disk artifacts, like node_modules/ and package lockfiles. Switching branches doesn't help me manage those artifacts, and might require a full teardown and rebuild of my dev environment each switch. Even if I maintain a meticulous commit history and never have uncommitted "WIP stuff" that I need to stash, switching from my branch to fix a bug in the main branch could be annoying and intrusive just because of the dev environment. This is a great case for a separate worktree.
This is kind-of the million dollar question, though, I think? What would such a reason be?
(I ask from a perspective of genuine curiosity, not of implying that you're wrong to have them)
Just for the purposes of comparison - my own "bright line between [good and bad]" is "does the commit message just contain 'WIP', or is it actually fully written-out?" - but I can see that "is the work committed or not?" also works. Thanks for explaining!
On some _very_ rare occasions, I might find that, by the time I've gotten the change to a reviewable state, it's actually too large to be meaningfully reviewed in one go, in which case I'll go back and retroactively (re-)implement it reviewable-chunk-by-reviewable-chunk (on a different branch), and get each of them reviewed and merged in turn. But, 99% of the time, I simply:
* use WIP commits as "checkpoints" along the way while implementing
* get to a minimal mergable change
* use `rebase -i` to squash everything into a single, well-written, reviewable commit
* rinse and repeat