The better understood, both in capability and limitation.
The better chance no new updates will break it.
The better chance no new updates.
The better you get to know it.
The better you get to integrate it.
The better the chance it will be there tomorrow too.
The better the investment learning it becomes.
And also you don't get to integrate it very well if everything around it isn't maintained, and compatible on old version of a library (with said documentation not existing anymore).
Also, while resume-driven development is not a good thing either, it's certainly not a good investment to pigeonhole your career into working with something you hate working with.
But remember to use the right tool for the right job - older isn't always better. E.g. there is a set of people who use stored procedures for everything and it does make sense when you are doing data-heavy processing on database-side. But using that for everything, even when the volume is absurdly low, is a bad idea - using a language like Java would be a million time more flexible, composable, testable (unit tests, anyone?) and allow making changes with greater confidence.
Long enough for the rough edges to be softened, to show that people are willing to maintain it, for detractors to have pointed out legitimate issues, for the tech to become stable.
I’d prefer 10 years personally, but I value stability more than most. I dislike revisiting problems I’ve already solved.