I do this. Some colleagues don't leave work until they've finished the feature/bug they're working on.
If it's 6pm and I'm stuck solving a bug, I call it quits and go home. Often the next day I have a new perspective and check that other place where the bug actually comes from, and solve it faster than if I had just banged my head until late.
With respect, your comment and the GP comment seem to be two different things.
(1) Stop work when the immediate path forward is clear, so there is less friction to restarting.
(2) Stop work when encountering a puzzling obstacle, with the expectation that ambient thinking will suggest a path forward.
I try to do both of these things. I'm more successful with the second.
I first read about (1) in a book on writing technical papers, where the advice was to NOT write until you've become confused about the way forward. Rather, leave off so you know how to begin on the next writing session.
The right strategy could depend on the application!
If it's 6pm and I'm stuck solving a bug, I call it quits and go home. Often the next day I have a new perspective and check that other place where the bug actually comes from, and solve it faster than if I had just banged my head until late.