Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority' for years. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it.
With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance.
(Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)
As a project maintainer, I don't want to close unfixed issues because they become much harder to find (hidden by default), which results in duplicate reports if it turns out the issue is not fixed. Also it can be rude, if it was a high effort bug report.
At the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with.
The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.
But it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed -- but this is not a separate bin).
When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs.
To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed.
I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good.
It's tough. But the dude abides.
Closing bugs just to make dashboards/metrics look better is wrong; either adjust the dashboard or fix the bugs.
But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed.
If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.