As with everything examples are the best way. Some examples you can give:
- Hard to change code: Bug X took 3 days to fix caused by code issues a,b,c
- Tight coupling: Fixing Bug Y introduced bug G, fixing both causes bug F
- Hard to read: It took 1 whole day to investigate bug C
- Bad cohesion: Introducing feature D required dependency on F, which is unrelated. This causes problems such as circular dependency problem a, build time increase b etc...
To put this simply if you can draw a cause and effect line and illustrate with bug tracker records, e-mails and other forms of proof that indicate that there is a problem that should motivate refactoring quite easily. "It shouldn't have taken 2 weeks to implement feature X!"
There are tools out there that can help you motivate your refactoring too. They can draw dependency graphs or show code complexity, duplication etc. If a tool reports thousands of warnings and management ignores it then there is no hope for management.
These focus on code structure changes. Small refactorings like naming conventions and pulling up into base classes are things that I consider part of my job, and I don't ask permission to do it. If it's going to impact productivity or delivery date significantly then it is worth asking permission.