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.
Yeah, well, if it weren't so full of decades-old still-unsolved bugs, then maybe the product would have more users and therefore more revenue?
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.
It's all about finding the right balance.
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".