As for the question of tools – there will really never be an instance where an IDE can really help you. Part of the problem is that so many libraries, tools and framework rely on "method_missing" to handle functionality. It would be challenging if not down-right impossible for an IDE to fathom what would be an acceptable "method" name under these circumstances (as a point of reference, ActiveRecord makes heavy use of "method_missing")

http://www.dotrb.com/2007/8/11/scaling-rails-with-sysloglogger

Whether the language is compiled or interpreted I think is really immaterial. The issue is how much your IDE can help you. If your language is statically typed, your IDE should be able to do a lot in terms of figuring out what will work at coding time. If your language is dynamically typed, then it's not so obvious. But depending on how you write your code, your IDE might still be able to help a fair bit. If your framework creates many of the methods you use on the fly by doing string manipulation on the method name, like Rails does, your IDE is hosed. It won't be able to help at all.

A side effect of this coding style is that even basic syntax errors won't get caught at compile time — in fact at run time the stack traces typically include 5-10 lines after your bad line of code where Rails is trying to figure out what you might have meant.

All this points to a system where developer productivity is fabulously high when you get started, but is severely limited by the tools once things start to go wrong as they inevitably will with a big project.

You're right — the language isn't the limitation. It's the coding style that is adopted/encouraged by the framework. It's totally possible to write maintainable code in perl or smalltalk or ruby. I've never worked with smalltalk, but I know almost nobody who writes maintainable perl, and I'm having my doubts about ruby especially on rails.