That doesn't seem like a fair characterization. The distinction between "refactoring" and "implementing a feature" is not always very clear. If a new feature violates some assumption of a dependent API, do you hack around it or refactor the dependent API to take change the underlying assumption. The refactor may not be strictly necessary to get the feature to work, but an experience developer may understand that the hack, quick solution will cause other more serious issues later and choose to do more work up front to head it off. Should that be a new ticket or a separate task? Maybe. We have to make judgements calls all the time on stuff like that and I don't think it is really possible to micromanage development of a complex application that way.
