For example, rubygems (probably my least favorite ruby
  software of all time) basically require that you always try
  to load them, because their design stupidly requires that 
  you know whether a given piece of software is installed via 
  rubygems or some other mechanism.

Nearly all libraries nowadays are installed via RubyGems. For most of its life, RubyGems has been the "de facto" way to install libraries, but not the 100% officially-sanctioned route. As such, it's necessary to require RubyGems in first, then the libraries you want to load. This takes all of 10 seconds to learn.

The poster has missed the point somewhat when it comes to the use of vendor. "vendor" is used in situations where you have to remain fixed to a certain version of a certain library AND you're not 100% confident that your deployment environment will have that version of the library installed. In this way, it's a better solution than just praying the remote server has a certain library installed or ending up with a script that fails on the library version assertion, as with Perl. Overusing vendor is, however, a lazy way of doing things, and the sloppy programmers this guy has spoken to do not represent the community as a whole.

From the comments:

  To me, this is one of the really big things that defines 
  Perl as a mature language community: Perl people don't do 
  this nonsense.  There's no "vendor," and you're looked at 
  like you're out of your mind if you distribute copies of 
  other people's modules with yours instead of declaring 
  versioned dependencies in your Makefile.PL. 

(Good) Ruby people don't do this nonsense either. RubyGems supports you specifying the gem name and required version (or required minimum version) in a similar, or better, way than Perl.

This is an over-rated post telling us about a problem that only exists in the ignorant. It's cut from the same cloth as all the misinformed "Twitter's Dropping Rails!" posts and I'd expect better from the voters on HN.