The old rubyforge.org (based on GForge) had many of those features. rubygems.org (based on the gemcutter) is still rather new, and could use some more features (ranking would be nice).

There is a huge push for moving away from C extensions, and towards using FFI (Foreign Function Interface).

There are four main options for XML parsing in Ruby. REXML (bundled with Ruby stdlib), Hpricot (legacy), libxml-ruby, Nokogiri (very popular). As for documentation, there is rubydoc.info.

You seem to have an outdated understanding of the Ruby community (you point out Rails-centric problems from ~2006).

The Ruby community is obsessed with testing and documentation. You cannot get +2 line patches accepted without tests accompanying them. It's common to test your projects against all the major Ruby VMs (1.8.7, 1.9.2, JRuby and Rubinius) using RVM. YARD and rubydoc.info have recently gained a significant following.

Not many developers prefer to use monkey-patching these days. It's a powerful tool, but one can avoid using it by including/extending Modules. Also, Ruby 2.0 will be introducing a new feature known as class-boxes (aka Refinements), which will compartmentalize monkey-patches to modules.

There are alternatives to ActiveRecord, such as DataMapper which has had Strategic Eager Loading (SEL) and Lazy Loading long before ActiveRecord 3 was released. But what do ORMs or ActiveRecord have to do with the number/quality of gems on rubygems.org?

tldr; Rails community != Ruby community

Frightfully obvious. Once the hardware is installed, it opens up potential for massive abuse.

The future will indeed be interesting.