That isn't closing them "just because they're old" though.
That is closing them in a "WONTFIX" state. This is perfectly valid for minor irritations or matters that the maintainers don't agree are bugs at all, though some (entitled) bug reporters will take umbrage with it especially if they've taken the time to actually produce a good bug report rather than just a vague "X doesn't work" or "Y breaks Z".
If closing in a WONTFIX state, a brief explanation added to the ticket is a good idea, to reduce the risk of future time wasted because it is simply reopened as a new bug. For instance: you might be closing it in that state because it will become irrelevant shortly due to other work (perhaps the feature is changing considerably which will render the issue moot), because you don't consider it a bug (i.e. behaviour by design) or fixing to some satisfactory standard is something there isn't time for (i.e. your "not ever likely to be a priority" status). In the "not ever likely to be a priority" case, perhaps suggest that a PR addressing the issue matching your coding standards (assuming you have them documented) would be welcome, though only do that if such a PR would have a change of being given the relevant assessment time.
That is closing them in a "WONTFIX" state. This is perfectly valid for minor irritations or matters that the maintainers don't agree are bugs at all, though some (entitled) bug reporters will take umbrage with it especially if they've taken the time to actually produce a good bug report rather than just a vague "X doesn't work" or "Y breaks Z".
If closing in a WONTFIX state, a brief explanation added to the ticket is a good idea, to reduce the risk of future time wasted because it is simply reopened as a new bug. For instance: you might be closing it in that state because it will become irrelevant shortly due to other work (perhaps the feature is changing considerably which will render the issue moot), because you don't consider it a bug (i.e. behaviour by design) or fixing to some satisfactory standard is something there isn't time for (i.e. your "not ever likely to be a priority" status). In the "not ever likely to be a priority" case, perhaps suggest that a PR addressing the issue matching your coding standards (assuming you have them documented) would be welcome, though only do that if such a PR would have a change of being given the relevant assessment time.