Refactoring is one of the key technical practices in the Agile developer's toolkit. Refactoring also has no measurable customer value by its very definition - it involves changing the structure (design) while maintaining the behavior. In the Lean world - anything that does not have customer value is waste, and a customer only perceives behavior/functionality and not structure.
But there are two types of waste in Lean: pure waste, and necessary waste. Pure waste is one that has no value to either the team building the software or the customer using the software. Necessary waste, on the other hand, is the best way we currently know how to do a job even if it does not have customer value. Refactoring is clearly an instance of the latter.
So, why call something out as necessary waste if it is valuable anyway? Well, the point is, it is not valuable to the customer. Therefore we should minimize it and be constantly looking for better ways to do what we do without it. But, if we do not recognize it as a waste it will never be addressed because our perception of it is that it is the only way of doing things correctly. (Think Big Upfront Design.)
If you are with me so far, then the next logical question is "so what? How does this change things?" By seeing Refactoring as a necessary waste, then a developer will minimize refactoring; that is only refactor code that no longer meets the requirements of the user. This means, when you are coding away and you see a method in the class you are modifying that "smell's bad" but has no direct connection to the requirement you are working on, you leave it alone.