I don't presume to know your work environment, but personally I work on my own projects and do contract work and, in my experience, taking on debt is usually a sign that there's a problem with the requirements and estimates, so I usually change those before making the code less maintainable (which, IMO, is usually a case of treating the symptom).

Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".

Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.