I'm going to side more with Elad in this discussion than Vitaly.  Over
the years, I've definitely done my share of reaching across the MVC
divide, putting methods in the "wrong" place.  And nearly every time
I've done so, I've regretted it -- either because it made the code
harder to read, or harder to test, or less modular.

I'm willing to be flexible (or un-dogmatic, if you prefer) when it comes
to controllers sometimes doing a bit of model-related stuff.  But
putting controller-type logic in the view is something I try to avoid.  
Putting controller-type or view-type logic in models strikes me as
something that there's almost no good reason to do.  Vitaly's argument
doesn't totally convince me; while I'm sympathetic to wanting to have
various URLs produced by a model's .to_xml method, the moment that you
start to import helper methods into a model, the red lights should start
flashing.

As Elad wrote, the model shouldn't ever know about the HTTP request or
handle it; the power of MVC is in the decoupling of such things.  There
have been some occasions on which I've used ActiveRecord outside of a
Web application -- yes, such software exists! -- and the fact that the
model neither knew nor cared about an HTTP request was obviously quite
helpful, and allowed me to reuse the code.

Vitaly, I looked at your blog post
(http://blog.astrails.com/2009/10/27/liberate-my-controller); perhaps
you didn't notice, but all of the people commenting on the post said
that they disagreed with you, and suggested alternatives.  This doesn't
necessarily mean that you were wrong and they were right, but it should
give you pause before suggesting that this is a practice others should
follow.

Finally, I've been using metric_fu quite a bit to look over my code.  
I've found that while I sometimes disagree with the points that it
makes, and find them to be extreme (e.g., the notion that no method
should be longer than six lines), it does help to push me to make my
code more elegant, readable, and testable.  On a number of occasions,
I've rewritten things according to suggestions provided by Reek, for
example, trying to "prove" that my implementation was just fine -- and
lo and behold, when I started to change things to adhere to Reek's
suggestions, I've been surprised by the improvement that has emerged.

Reuven