I've seen visual tools make me very productive, and other times get in the way big time. One lesson I learned is that visual tools are seductive. They make things appear easy, when in fact they could be screwing you over in terms of the design of what you're building. For static visual interfaces, visual tools are nice, because you can accurately place things where you want them on a screen. You don't have to wait for a compile step, though in Rails all you need do is a refresh on your browser to see what's going on.
One thing that is really nice about an IDE is full-screen debugging. My (limited) experience with Rails is all you have is line debugging. Reading up a bit on it just now, you can also output to a log file. Also saw somebody say they preferred this to using a GUI, maybe because of the difficulties that using a GUI presents to designing a good dev. environment that works reliably cross-platform on a network.
For server-end stuff sometimes logging is nice to have, but in my experience with using .Net for server-end stuff, I much preferred being able to step through my code as I was using an app., or calling a web service, and to be able to see the code around it, in context.
As I tried to say in a comment on your last post on Ruby (it went into the black hole), I checked out Rails 5-1/2 years ago, then discovered Squeak and Seaside, and found that more to my taste. You get the advantage of a good OOP environment, an IDE (Squeak's built-in tools), and a web interface that you can inspect (as a collection of visual objects) and edit in real time (this can be turned off for deployment). At the time I looked at it, there were database APIs, but no schema framework like what Rails has. I've been out of that scene for 3 years, so I have no idea what they've done with it since then.