That said, if you have a pure function, and you need to know the current time, consider keeping it pure with DI.
- controllers should not touch the data layer directly (and therefore follow SRP)
- controllers should have their business layer services injected from somewhere else
This does not make them pure in the sense they remain (indirectly) functions with side-effects, by virtue on relying on business services, which themselves interact with data access services which do IO. However, it does make them testable without resorting to hacks and offers a clean interface.
I'm confused about your comment regarding productivity. Either my recommendations are mostly valid, in the sense that they offer a distinct advantage over the current, Rails-y way of doing things, or they are not (but in which case you would need to make a cogent argument for why they are not). If they are, surely recognizing the shortcomings of a particular design/set of accepted practices is a benefit.
The fact that Rails 3 has undergone significant architectural changes with the merge of Merb shows that Rails did not emerge perfect from the thigh of DHH. And we all strive to improve ourselves and the tools we work with (or alternatively, for those of us for whom this is not an option, we stay with PHP or VB and stare blindly at people talking about "MVC").
http://en.wikipedia.org/wiki/Single_responsibility_principle