"actively harmful for the vast majority of use cases" but you've discounted the effect of burnout on maintainers, who are the vast minority of individuals.

This effect must not be understated, sustainability is a primary concern, as you'll see at the top of this thread, I started with "not every project has an active maintainer" - this is not always a state that arises in a perfect vacuum or even over a well-defined span of time, when an author loses interest in their creation and stops contributing to it. It is a terminal state in a state diagram with many open loops, and perhaps one to be avoided if you're keen on maintainers triaging issues! But also sometimes unavoidable.

If the active maintainers are all chased away by hungry users, clamoring for architectural changes without a full understanding of the project and how it's designed to work, then there is value in a bot chasing away the people who are just window shopping for something completely else than what you sold them, or even what else you had planned in your as-yet unexpressed vision for the future.

Spending the spoons required for an interaction is not without a compounding cost in all cases either. If your response is not simply accepted, or it's actually reiterating just what you already knew the user didn't want to hear, well... you've now entered the "bargaining" or "negotiating" phase of issue triage, and the next step is... well, another step

I negotiate with those users because they usually have valuable insights hidden inside of their pain! Our lead maintainers would spend time doing the same, but the more time they spend on that, the less time they have to spend on writing code and actually developing the software.

See how this model basically hinges on adding more people to the maintainers team as the user base scales up? And to the point, sacrificing some of their labor in service of triage role activities? If you are a single maintainer for many repos, you desperately need to avoid becoming a customer service bot for your non-paying customer-users. Spending time servicing those users can result in negative feedback loops where people expect more attention just because you gave it once. This has not been my experience most of the time, but...

...And that's not to say the issue queue won't be used for something else... but... maybe just your issue didn't make the cut. And that's not an affirmative value judgement – it just means maybe it did not make the cut for that maintainer's roadmap, who owns the queue, even if such person currently exists. Like I said, nobody signs up as "repo owner" when they publish their work, but it is their queue.

Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."

It really might not actually be that they ignored your PR/report just because they want to kill the project? Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.

If you've gone to all the trouble to track down 16 issues that provided details about the same report when they were all closed then you know it's possible, they aren't inaccessible just because they've been closed; it's just a bit frustrating – maybe also notice an important indicator of the volume over quality of the average issue submissions that 15 people didn't search well enough to find a closed issue that was a dupe of their issue! Did they even search before posting at all?

Anyway, if you're doing all that, then bottom line you should absolutely be a maintainer. Add yourself to the MAINTAINERS file and then go ahead and turn that stalebot off! ;)