Perhaps because it's in maintenance mode and what you really need is just to be able to run it to compare its behavior with that of its replacement, or because you want to perform the upgrade by replacing code that relies on deprecated APIs in an incremental way, in a copy of the codebase that still runs and passes tests at each step along the way.
Or maybe you're a scientist and you want to run the original code because you want your tests to have the exact same performance and other characteristics as the code used in the original paper, so you want to avoid compiler/interpreter optimizations that have come out in the meantime.
Clearly you shouldn't dust off a Ruby 1.8.7 app and deploy it to prod, but what would be the harm in using a script you wrote in 2012, say, to batch process a CSV to JSON?
In fact, the project you're dusting off might just be an old revision of your current app that you already ported (over the years) to current standards, but you thought you wouldn't need that script so you deleted it 7 years ago rather than keep it up to date. if you could check out the old tag and run the script intact, that would be ideal.
But wouldn't you want to update your project to a new(er) version of Ruby in that hypothetical?
There have probably been security updates along the way.