It was clearly a natural stopping point in that you stopped working on the code for the amount of time it took to switch. There's nothing wrong with encoding natural stopping points in your commit history, even when those natural stopping points don't always align with semantic stopping points (features/fixes/completed tasks). Sometimes those natural stopping points even encode data you might miss later: sometimes in making that switch you also mentally switch tracks and looking at where you stopped and where you restarted sometimes can remind you of things you forgot in between. I've found debugging cases where that helped me solve problems. (That said, in practice I rarely keep such "natural stop commits" myself, but I've also never been strict about it and sometimes keep them. There's nothing wrong with them and sometimes they are useful "waterline" markers in a larger effort.)
I don't make these commits often either, they exist almost exclusively to move code across machines. Actually, I commit much less frequently than most people, keeping most of my work in the staging area for long periods of time until it's ready to be committed. Probably a bad strategy, but it keeps my code clean…
My point is no matter what your commit strategy is, the reality of what actually happened is debugging info, and worth preserving to help debug later. While debugging and digging through history I'm often asking the question "what were they thinking?", and the info that you made a commit just to move to a different machine might make me e.g. consider it more likely that you left something out, or stopped a line of development early because you needed to do the commit earlier than you normally would. Squashing tries to hide the "how" and "in which order" so you only get the "what" of what was developed. But "how" and "in which order" are valuable pieces of information too.
