I've mixed feelings on this still. It leads to big code reviews, with most of the changes being less important. So I rather like the separation, spend some time just for cleanup. Maybe take notes on wins as you see them but you don't need to do them yet (or put them in the same review as another bug fix / story item).
If you're using git and can separate things out cleanly then I think fixing it as you go would work better. I yearn to use git every day again...
Well, I'm not talking about a major refactor (squash them when you see them). This should be an enum, this is named poorly, this variable is scoped wrong, inline sql when should be a sproc, that kinda stuff. A few lines a fix, the low hanging fruit.
Major refactors certainly need to be accounted for in a sprint(s), but keep features a priority when needed in sprints.
If you're using git and can separate things out cleanly then I think fixing it as you go would work better. I yearn to use git every day again...