Software quality, even according to ISO standards, is much more than three points. Refactoring can be targeted at any combination of them.

I've always thought that refactoring is not just any decoupling, and not about cohesion. I am trying to look into problem domain to find a better composition of the code. Thus, the main reason for refactoring is adjusting code to the latest mature knowledge about the problem domain. The second most valuable indicator is vertical composition of the code, according to the hierarchy of abstractions (or whatever organizational principle the software architecture sticks with).

Thus, probably the biggest reasons for refactoring are maintainability and modifiability, and ultimately, decreasing the complexity (making complexity more adequate to the problem domain).

Some refactorings are done because of optimizations. (Even factoring something out in arithmetics can be seen as an example of optimization of calculations). Testability and reusability are useful side-effects once you discover where software growth points are and make it possible to add new operations or components ideally in just one place.