Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.

Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.

Closing bugs because they can no longer be reproduced: obviously fine.

Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.

the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.

if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.

otherwise you're just throwing away useful information.

edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem