I love you bring in chunking as a main idea here. Your suggestions focus on the relevance chunking plays in developing the ability of refactoring.
I'd like to add the perspective of using chunking as one key driver in envisioning the desired output of many (yet not all) refactorings: in legacy code the first thing I encounter is usually a mixture of various levels of abstractions in one intermingled piece of code: from low-level bit-wise checks of something to broader steps. My goal then is to transform it into chunks that live on the same level of abstraction, so lets say a method is then reduced to an expression of a line of thought that can be easily understood at the first glance (max. 7+-2 chunks of steps, following the famous article on the magical number seven -- yet preferably much less, like 2 or 3). And the first thing to do often is extract method. Achieving this usually tells me when to call my first iteration of refactoring done, and move on to some other code.
Quite some other refactorings for me might make me do all sorts of tricks but in the end they serve the same purpose: producing chunks of code easier to grasp. Even refactorings like "replace branching with inheritance" follow the same goal for me: create resulting code that is properly chunked in the key expression of e.g. an algorithm.
Well ... at least that's my current state of evolution in my learning of refactoring ;-) ... I'm curious what will emerge for me the more experience I gain.
Usually I'm already happy when the parts of code with the highest level of abstraction get some proper chunking level. I might go down one or two more levels and refactor there, too. But often I leave less-than-perfect-code on "lower levels" for the next boy scout visiting the camp ground another time (which might be me ;-)...).