It's certainly worth questioning whether it applies to software... I suspect the idea behind your thought is that there is no inventory cost to issues since they are just a few bits on a hard drive somewhere.
But I'm not so sure that's true. Every minute that passes after a bug report has costs: the reporter's memory slowly degrades making it harder to reconstruct the triggering scenario. The software itself slowly drifts away from the state the bug was filed in, adding questions about whether it's still applicable. And recent changes to the codebase that might have triggered the bug also slowly fade from developers' memory. Lastly the larger the bug database is, the harder it is to search and the slower de-duping becomes.
In a real sense the value of the report decreases AND the cost of addressing it increases over time.
Would be a clear indication that this isn't the heathy version that you describe but rather the unhealthy version the author suggests.
At some point your bug tracker becomes noise and you just never deal with it. I have seen it happen, and cleaning it up is a whole separate set of pain.
Judging from the graph it looks like Jira is the tracker in this essay. There's so much horrible UX in Jira it's very likely to be part of the problem. Coping with any volume of bulk data in Jira is a nightmare - for a PM or engineering manager you end up having to most of the prioritization in your head.
I'd like to see issue tracking tools on the market that take what we've learned about data visualization in fields like data journalism. Some of the UI elements of OpenRefine, for example, would be huge step forward