This is what I often do, however with larger repositories (where people have a bad habit of committing files that they probably shouldn't be, blowing out the size of the repo significantly), this can also be slow! But of course, this all comes down to your specific circumstances.
Mine were exacerbated by the fact that the bulk of the team didn't really understand git very well, and bouncing between features at a super rapid pace meant I could get into some slightly odd situations. Nothing a bit of git-fu can't fix normally, but can take a little bit of wrangling or forethought.
You could. I work with Firefox and that code base is huge so it's not a good idea to download 15+ gigs every time you don't know how to do something. Learning the tools is a more sustainable way to go.
Make an external worktree.
No need to re-clone the whole repo, nor stashing/commiting your work, switching branch, doing the merge, etc (which you may know how to do, but is a pain if you often need to do so)
Mine were exacerbated by the fact that the bulk of the team didn't really understand git very well, and bouncing between features at a super rapid pace meant I could get into some slightly odd situations. Nothing a bit of git-fu can't fix normally, but can take a little bit of wrangling or forethought.