I (at the risk of getting horribly off-topic) attribute this to Rails' origins, namely a team that moved to Ruby from PHP, and brought too much PHP with them. Not to take a position on PHP itself, but it's a very different language, and what makes sense in PHP can be very ugly in Ruby.
Huge, ugly string evals (just one of the horrors lurking in the Rails codebase; their copious abuse of BasicObject comes to mind) are bad enough, but the code-generating is responsible for most Rails applications, too. The inherent ugliness of generating application code from templates in Ruby is one thing, but it would be ugly in any object-oriented language: you use inheritance, and defer to the superclass (or, in languages that have mixins or prototypical inheritance, you add a class/exemplar to defer to). You don't take the behavior you expect these objects to exhibit, stuff it into a template, and write a script that fills in the blanks and dumps the result into a file. It's automated copy-paste, an optimized version of something that was a bad idea to begin with.
(I've heard good things about Rails 3.0, but I've not looked. My heart has been broken too many times, and I don't see Yehuda Katz as substantially more insightful than DHH.)
As for code-generation, I think you misunderstand their role in Rails. Can I ask you, in your editor of choice do you have any kind of snippet/template functionality (e.g. yas for emacs)? Same deal.
The number of times the string "BasicObject" or "BlankSlate" shows up in the codebase is not representative of the times an instance of a class that inherits from this class shows up in data I am passing around. And the number of times an instance shows up is not representative of the pain I have gone through with these misapplied patterns. Between these, HashWithIndifferentAccess, the liberal use of :nodoc: tags (to the non-Rubyist: these--distressingly--suppress the API documentation generator from generating documentation for a given piece of code), and other "quirks" of the framework, I have had a hell of a time debugging in Rails.[1]
> I think you misunderstand their role in Rails.
I seriously doubt that, but I'm more than willing to hear what they are if not essentially copypasta generated for developers to tweak. It's a case where inheritance and mixins would have done nicely and resulted in cleaner code. If you don't believe me, try taking one of these generated controllers, stuffing it into lib/, renaming it appropriately ("GenericController", for example), and having most of your controllers inherit from it instead of ActionController::Base directly. The result is a lot of mostly empty controllers where behavior that varies from the GenericController is easy to spot, because it's the only behavior that needs to be specified.
> in your editor of choice do you have any kind of snippet/template functionality
As bloated as my favorite editor is, I am sure there is some functionality like that, but I don't know where it is or how to use it. Not that I don't generate code ever; it's a fine technique for a dirty hack, a script that needs to just be done and cleanliness be damned. It is not how I would engineer an application that I expected to have to maintain, and it's undesirable for that to be the main pattern of development in a framework.
1. Please do not think that this is because I am new to Ruby or to Rails. I have been doing Ruby professionally since before Rails was released, and spent a few years doing Rails almost exclusively, starting before Mongrel came out and our choices were WEBrick or FastCGI. I still occasionally have to interact with Rails codebases, although I have been trying to avoid it for a long time.
Huge, ugly string evals (just one of the horrors lurking in the Rails codebase; their copious abuse of BasicObject comes to mind) are bad enough, but the code-generating is responsible for most Rails applications, too. The inherent ugliness of generating application code from templates in Ruby is one thing, but it would be ugly in any object-oriented language: you use inheritance, and defer to the superclass (or, in languages that have mixins or prototypical inheritance, you add a class/exemplar to defer to). You don't take the behavior you expect these objects to exhibit, stuff it into a template, and write a script that fills in the blanks and dumps the result into a file. It's automated copy-paste, an optimized version of something that was a bad idea to begin with.
(I've heard good things about Rails 3.0, but I've not looked. My heart has been broken too many times, and I don't see Yehuda Katz as substantially more insightful than DHH.)