I don't have a particular pro/con opinion on the suggestion itself, but I do agree with the problem
that we often end up finding old(er) documentation by default - most certainly when doing a search
through Google but perhaps also by using other search sites (not sure, but possibly so).
I myself run into this problem every now and then. Often it helps if I use a link such as
https://ruby-doc.org/stdlib instead, rather than the specific version, but sometimes even this
leads to problems/errors such as non-existing pages. So from this point of view, I think it would
be useful if we could do something about it. (Although I am not sure how much control one has
over ruby-doc.org, but perhaps using something like https://doc.ruby-lang.org would be better
anyway).
Again - I have no particular pro/con opinion on the "hiding EOL releases" per se (perhaps that has
problems or drawbacks), but I do think that this can indeed cause slight frustration. I would
assume that the most natural goal is to find current up-to-date documentation, but sometimes
people will find documentation for ruby 1.9 or something like that, and that is really really
quite outdated; only a small fraction of users would prefer 1.9 docs over, say, 2.5 docs or
similar. I understand a "third-party issue", but I believe even then it would be in the best
interest for ruby as a whole to be able to tell people to refer to the most current documentation,
even if Google is to be blamed for it (but even the Google engineers should agree that it
may be more useful for people to see more recent documentation, so something is strange in
their algorithms in that case if they prioritize e. g. 1.9.x over 2.5.x or so - perhaps
someone can tell them to have a look at it from their side too).
For what's its worth, rubygems.org works fairly nice. One can use markdown files for documentation
and while markdown may not be perfect, I think it is very useful and very simple. It's quite
simple on rubygems.org to find most up-to-date documentation for gems. Perhaps in the long run
it may be worthwhile to see if the core docs would also use something like that or perhaps even
be hosted at rubygems.org too (at the least the gems there), but I guess this may take longer;
just may require discussion for future. Some ruby core contributors are very active in this
regard (in general), e. g. Hiroshi Shibata but of course others as well. Of course this is only
my personal opinion that rubygems.org may work better here than ruby-doc.org, so your mileage
may vary.
So from a general point of view about the underlying issue(s), I agree with nelhage.
Updated by 
Updated by