Wise decision. Ruby has it's own package system. I believe every developer using rvm/rbenv for managing ruby versions. Rails should be installed using rubygems. I always cry seeing pretty outdated rails packages in distributives. I don't care.
If you don't think that's a problem in the real world, you ain't seen 95% of enterprise IT.
(This problem not confined to Ruby)
And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.
In particular, none of them yet solve the problems of client application deployment. They are also implicated in the VM sprawl many cloud users experience.
Finally, they have convinced some developers that systems administration is something they can do themselves. Experience consistently proves this wrong; I've lost count of developers out of their depth, asking for rescue from suboptimal deployment decisions and needing rescuing. Either that or they discover a penchant for systems admin as well, and thus become devops people (this is what happened to me). I've seen the latter happen most often in the ISP world; perhaps network engineers have that mindset.
Personally I foresee a stronger role for packages as an output from continuous integration pipelines (another young discipline).
I'm not sure what you mean by clients though and how that relates to VM sprawl.
It's true that some developers are convinced that sys admin is something they can do themselves. However, it goes the other way around too, that sys admins think they know what is best for the app. It's better all around if devs actually gain an understanding at the issues with sys admin, and sys admins get some development skills.
As far as the server-side goes, once nice thing about using something like Chef or Puppet is that you can create a miniature version of the production environment on the developer's laptop. You won't run into the same kind of issues when you are scaling out, but you can at least make sure that you are running everything rather than always developing things in isolation.
Ruby has rubygems, Python has pip, Perl has cpan...
Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up correctly. They could delegate that function to RubyGems, it'd be transparent to the user.
Some package managers go down a more drastic route and simply tell the user to install the dependency through the correct package manager (Homebrew does that with Node, top of my mind). Users can still do it locally with rbenv/rvm/chruby if they want, it doesn't change much.
The bigger I'd think is that they don't want to rely on external package managers for the stability of their system. Which is a very valid reason, if RubyGems is out you can't install certain ports. Or worse, the gems aren't safe. The system is then self-contained and tested, proven to work with the provided copies of gems.
But as a simple dependency resolution perspective I don't see it being the case.
As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities.
We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are often bespoke and written for specific needs.
Non-OS installation is a huge barrier to new users of a Ruby application. I installed Gitlab recently. Take a look at the length of the installation guide [1]. There are seven numbered steps, some of which involve multiple commands.
Upgrading from 4.0 to 4.1 was about the same complexity.
Thanks to the thoroughness of its author, the guide largely worked as advertised. But being able to install and upgrade with apt-get would have saved me hours.
[1] https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install...
Aside from the fact that that's redundant, it's highly error-prone.
In places where the IT staff insists on making sure this isn't "redundant", they usually use something like fpm to create a deb or an rpm out of the gem specified by Gemfile. Which you then have to drop into a custom deb/rpm repository. On top of that, the ops staff don't know how to do that properly, so they end up with a bunch of testing and development dependencies that the Rails application doesn't need.
... or, you have the deploy process call, "bundle install"
The redundancy is in the OS packages, not in application dependencies. So it is actually better to automate such with something like Chef and Puppet. From there, I can define exactly what the application needs from the OS.
I have seen this play out in a lot of ways, devs vs. sys admin. In the past, sys admins "win" since compute resources were still scarce. We're in the age of virtual machines now and configuration automation. Applications get their own VMs, sometimes in multiple nodes. We don't have Unix high priests guarding the altar with SSH keys, hand-deploying things in secret early-morning ceremonies. We have automation to deploy for us, which means we want to make it easier for the automation to deploy, not necessarily for someone to shell in and maneuver around with hand installations.
Things being application-centric, the "right" thing is to conform to the requirements of the dev team's app, not the other way around.