It seems like the use case he's optimizing for here is if you're accidentally on the wrong branch, and need to move your working changes over to the correct branch.
Personally, I almost always use stash if I'm not quite ready to commit, but need to quickly fix a bug that takes precedence over whatever I'm currently working on. I stash what I'm doing, fix it, and them come back. Some of these operations seem at odds with my workflow.
I've used that workflow too. What disturbs me about the `git switch` proposed here is the unstashing. I think the intended optimization is more general: when you're trying to switch to another branch for any reason but git doesn't let you because of unsaved changes. But your use case of being on the wrong branch seems like the actual optimization for a fairly (at least for me) uncommon workflow. More frequently I, like you, stash and switch, then possibly do something (or not) like immediate bug-fixing, then switch back and unstash only then.
"# Switches to branch. Stashes and restores unstaged changes."
I guess I can't think of anything in particular, but I feel like something unexpected could go wrong here.
(I didn't know you could pop a the last stash that was made on a given branch?)