It sounds a bit like the opposite side of the customer acquisition cost versus lifetime value.

Traditionally if you have a high user lifetime value you can spend more money on getting more customers by increasing your marketing spend so your CAC (customer acquisition cost)/LTV (lifetime value) stays at a good level. So you can keep a good growth curve.

In this case when your ltv is negative for each issue because of low quality, or simply too many of them then you make it harder for new issues to come in, which should ideally result in fewer but higher quality reports?

I have a question mark in there because I did not spend a lot of time considering this, but I like the thought.

yeah, I understand the practical side of the problem and is certainly not easy as you say. as for issue templates, reporting guidelines etc., they make it even less likely that people report a problem. as the article mentions, even on a project that encouraged feedback it was still not reported that it doesn't run on the mac. so my takeaway is that there shouldn't be any guidelines for issue reporting if someone wants to catch even a glimpse of the real issues. I'd say there should be a good process in line that deals with the issues and asks for necessary information afterwards, so potential reporters are not driven away by issue requirements. knowing this I'd say projects that have issue guidelines hurt themselves in the end.