I agree that auto-closing bugs is unfortunate, but I understand the motivation.
I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them.
Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".
Not sure if relevant to open source bug tracking, but I've worked in more than one company whose "old bug" policy boiled down to: If after we found this bug, we chose to ship an update that did not include a fix, then the bug is not important enough to ever fix and should be closed as "Won't Fix". In other words, customers have lived with this bug for at least two release cycles and the world didn't come to an end, so don't prioritize it. I don't agree with this policy but I think it's a pretty common mentality in the commercial software world.
EDIT: Additionally, I've never worked anywhere where the capacity/willingness to fix bugs exceeded the incoming rate. So net bug count minus fixes would always grow forever unless you regularly purged unfixed bugs. This seems almost universally true in software.
That's a good point in general, though the product example I gave was primarily funded by government contracts and (at least based on the negotiations) the contracts were far more sensitive to price than quality.
But I will say that my experience in enterprise software has been similar. The relationship between software quality and company success is more a bell curve than a linear one: if you neglect quality you'll certainly lose customers, but above a certain point if you spend too much of your budget fixing every bug you'll eventually lose to competitors with mediocre quality but lower prices and/or more capabilities.
I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them.
Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".