Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks:
1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment.
2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied.
Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.
And if not, the bug is probably not important. ¯\_(ツ)_/¯
At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.
And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.
At my last job, this was the attitude we eventually took with tickets that were several years old.
If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.
[0] when I say "customer", I'm talking about a department, not a single individual