As others have already stated, the problem is not convincing the programmers... it's convincing management. (If your programmers are writing "smelly" code and enjoying it, then you need new programmers.)
Management is justifiably reluctant: they're in the business of running a business, not of creating beautiful code. If it won't produce a benefit for the company then the programmers can just go home and write beautiful open-source on the free time -- code as a form of "public art" has never really caught on. But there is a business benefit -- the trick is to explain it.
The business benefit of "non-smelly" code is in maintenance costs. Shorter, more elegant code requires less effort to maintain. So the way to convince management is to track your developers' time in two categories: time spent writing original code and time spent maintaining existing code. If you can demonstrate that 5 hrs (or whatever is actual at your company) are spent in debugging and maintenance for every 1 hour of new development, then there is the beginning of an argument in favor of investing additional time and effort in cleaning up the existing code.
Another useful metaphor for convincing management is the concept of "technical debt". This is essentially the same argument (poorly designed code incurs increased maintenance costs) but it expresses it in financial terms -- and if you are trying to convince someone it is often useful to speak their language.
The key thing to remember is that management has no inherent interest in beautiful code (although your developers do -- or should), so to convince them you must address the real issue: the bottom line.