I'm using Ruby for a personal project of mine going on for about a year now, semi-fulltime. I'd like to add that I've been programming since I was 8 years old, and have a grasp of most common procedural languages except LISP and functional languages.
If you don't like Ruby because it's too powerful for you, fine. However for my needs, Ruby has really made my system of several processes faster to create, more dynamically flexible than I first envisioned, easier to extend and refactor. In fact, my experience has been so positive, that I have almost nothing negative to say about Ruby and ActiveRecord. This is because whatever hurdles I met, I overcame them, and often enhanced my system further by learning to do things better from the higher-level and down.
What you list as weaknesses of Ruby, as a quite experienced programmer, I see as benefits:
1) "Monkey patching": I have a few files where I extend basic objects like String, Object, etc., for use with serializing and mathematical extensions I required. No I don't "monkey patch" unless required, but native float is just too horrible, so I had to modify BigDecimal to make the core functions easier to use. I also combined Msgpack (faster serialize, but doesn't support all Ruby types) and Marshal (native serializing in Ruby), to be able to serialize everything over the faster Msgpack implementation as strings of Marshal. It is faster and more compact than just using Marshal. ActiveRecord was extended because I needed lightning fast mass "insert-or-updates" to DB, for which I used temporary db tables. A very simplistic one-liner is all that is required to update any of my tables with arrays of objects. Neato.
Now, the files and lines where I extended library and core functionality is not too great, and it allowed me to stich together already accessible functionality to improve performance, and making things more readable and accessible at the same time.
For very little effort, "monkey patching" enabled me to extend my very programming environment and libraries, something which in many languages are not possible.
Of course, when abused or misunderstood, this can be negative, just like a pistol is harmful in the hands of a child. When upgrading, of course, I'll need to review and test the code to see if something's changed. But these are very small drawbacks for me, and I have minimized and compartmentalized the code.
2) Duck typing: After using Ruby, I'm on the other side of the fence. I now see absolutely no reason to declare types anywhere. What I did instead is to create standard-code to dynamically check incoming arguments of all functions. That way, I can have a sort of one-sided contract behaviour, checking for *whatever* I want in the beginning of the function using instance_eval(), and save myself all the troubles of static types altogether, while enhancing my system at the same time.
I realize the standard Ruby libraries are missing such functionality, and also the efficient error-handling routines I created, but once you have such functions in place (what you need), I see no reason for static types. In fact, getting rid of types allows for more flexible arguments and handling, better fail-checks and faster development altogether. If something is wrong, often my argument- or paranoia-checking code is picking it up instantly. Neato.
3) ActiveRecord: Yes, it's ORM, but only if you want to. You can use db-depdendent, direct sql if you like, or get faster queries using arrays of arrays instead of the more general ActiveRecord objects. What ActiveRecord has done for me, is save me from endless work with SQLs, only to change them again and again. I've also extended the functionality of ActiveRecord, to deliver fast insert-update operations. If I were stuck with creating dozens of SQLs, I would probably have missed that opportunity to optimize. Because ActiveRecord freed me, but didn't bar me, from the low-levels, I was able to optimize more from the higher-level down.
Another thing ActiveRecord has done, is make my db schema totally normalized and efficient. Its model and naming convention has forced me to really think what is it exactly that I need, what are the relationships. In how many projects do you even have a normalized logical and physical model? Here I got it almost for free, just using the programming language constructs and trying to adhere to the standard. If you're having trouble with ActiveRecord, my bet is that you need to spend some time improving the normalization of your models.
I understand using ActiveRecord on an already-defined schema can mean trouble though. Its best fit is for new projects. I also don't use the migrations command-line tools, but just keep all models and dbobjects in my own separate files, and update the db when necessary. I'm not using Rails.
ORMs can be bad, but in my experience ActiveRecord does a good job of it, and doesn't force you anything you don't want. You should of course find out why things are slow when they are slow, and in my experience it IS possible to rectify all such cases. Don't shoot it down just because you're lazy.. See it as a RAD tool instead, which you should build on top of.. You can quickly get a working prototype, and then start optimizing. Isn't that the most agile approach anyways?
4) Ruby Gems: I dislike the native compiling and the hardware-dependent binary blobs, and the occational need to override the system-string. But once you've got it working, it's very neat. You can install / uninstall from commandline, and get impressive amounts of libraries and functionality. If you're spending too much time making general libraries, you're doing something wrong, because most can be had with the Ruby gems.
I haven't tried CPAN too much. Perl I can modify, but I absolutely hate the language syntaxes (yes, plural).
Ruby is for me elegant, simple and powerful. But it can become dangerous in the wrong hands.
There's no doubt in my mind that Ruby has made things possible for me in one year, which would probably take a good team several years to accomplish. You just have to see the possibilities and work smart.. You won't get top-notch low-level performance, but you might be able to squeeze out even better performance from working from the higher-level down.
How Ruby is in teams, is another matter.. ;) Rails is even more "fun" in teams ;)
However with some smart coding and some standards, such as my suggestions above, it should be possible to surpass productivity of most other languages, such as Perl and Java, because of Ruby's many advantages:
http://learnruby.com/about-ruby.html
So I see alot of neat possibilties in Ruby. Just wished there were better standard libraries for such important core functionality such as argument-checking, paranoia-checking (or program by contract) and errorhandling (standardized pretty-printing of errors with local variables, helpful context information from which function, line of the check that failed, line number, etc.)
However, even though some things were missing, Ruby did enable me to extend it for myself. Which is a good thing in my book.