Nicely put. Great things happen when we listen to what others means rather than what they say, and then respond to that => Get a shared understanding of the problem and solutions will come by themselves.
Rather than talking about compromise/equilibrium of refactoring vs features, I use another reasoning to make the code base better aligned with business. The reasoning is short (and simplified) : For a given feature, a good programmer will produce better code in less time than a bad programmer (that will have to stabilise a more complex solution). A programmer is good mostly because he has trained. So if a company wants better code, then better create a training environment than invest loads of time for refactoring.
I've found much less resistance to this than other approaches I've tried. I also think that life would be easier if we were better at demonstrating the business value of good code/architecture/infrastructure etc. That's what I'm working on right now.