If you're on a 3 year old version of the library because the library introduced a change which you will never be able to adopt so you're forever stuck on the 3 year old version, you're in a much worse position than if you're just 3 versions behind because you haven't taken the time to upgrade yet. As such, libyears become an optimistic measure of badness in that situation.
Nor did I claim it would. If you are auditing your dependencies like that then you don't need it, I said, as in it's not going to give you any extra information.
If you're not, and very many people are not, then total age of dependencies is a decent low-effort approximation for the probability of bug fixes affecting parts of dependencies that you're using.
That depends on the changes to the library since, and how and where the library is used.
Suppose I regularly generate a CSV file, all ASCII, where all the rows are integers or fixed precision numbers. I have a ten year old CSV library that processes that file, and has worked without any problem for ten years.
I have no interest in updating the library. Updates can introduce downtime, but provide no improvement. In fact, they introduce a slight performance hit because of new features and that I don't need. There is also the risk that the updates will introduce bugs, and then I'll have to spend time diagnosing the bug, and coming up with a fix.
Now let me reverse this: suppose there are two libraries to do the same task, A and B. They don't have the same features, but for your use case, they are both easy to use and do exactly what you need.
A was first released in the 1980s and was last updated five years ago. It's still maintained and is available in most Linux distributions.
B was first released three years ago and has had 20 updates since, 18 of which included fixes for security issues that don't affect A. (The website for A is regularly updated to indicate that it has been tested and these issues do not affect t.)
I see the overall point as not seeing every dependencies as things that need upgrade.
Any library that is effectively a dataset could fall into this as well: if you want to freeze your environment at a specific reference point and only update the actual moving parts, the libyear measurement won't be for you.
This reminds me of interface softwares that keep old version of some libraries to emulate the original behavior, butnin a controlled and isolated way.
