What's wrong with the feedback they get through traditional channels, though? There's already a GitHub issues page and the forums. There's no need to exfiltrate user data to figure out something they're already telling you.
They're looking for things like "how much usage does X thing get?", and this is hard to get from users for various reasons. You need lots of fine-grained feedback like menu clicks and things like that, you can't discover whether a button is easily discoverable from GitHub issues.
One way to do this is to make it a part of a beta program rather than baked into the main app. That makes it slightly more manageable for the developers too.
That's true, but I don't know how many would bother installing the beta, especially given that most distributions use stable. This would be the same as opt-in telemetry.
Windows Insider already had over 10 million users 4 years ago[0]. I'd say that approach works well enough. I myself used it on Windows Phone 8, because some upcoming updates came with cool features and being in the Insider program gave me earlier access.
I also used Firefox Nightly for a while because of the massive performance improvements at that time. As Audacity claims they're doing it for UX improvements, it would be easy to get frequent Audacity users interested in a beta build featuring tracking but also all the improvements being tested.
Github is in no way something that can be (or rather: is) used by anyone outside the tech bubble. Audacity however very much is. It is used by a lot of people that will never write a line of code and don't care (and shouldn't have to) about what github even is.
As someone who has done a little support work: The problem is that those channels require users to describe the problem to you. Many users are surprisingly bad at doing this.
It is possible to create opt-in, on-demand reporting tools.
Someone I know well created one such, based on a common reporting template of a major Free Software project, after realising that the template itself was based on information readily obtained from the system. Fleshing that out a bit resulted in an automatic syste self-documentation tool. They'd introduced it to the support group at one former company, and informal feedback several years later was that this was the principle diagnostic utility for the team. There was no ongoing telemetry, merely a "here's the script, run it and send us the output". (If necessary, the output could have been automatically emailed or transmitted by other means.)
There are now several of these, the "About This Mac" utility on OSX, as well as several for Linux, of which I'm aware.
No, they're not app-specific diagnostics, but precisely the same principles apply.
I would argue in OSS it doesn't work well, just because volunteers are going through and triaging most of the worthless reports (if you're lucky!) out it's still boiling the ocean, it's hard to put "this sucks and fuck you" on a backlog.
You can't really compare unstructured feedback in a forum / issue tracker to getting detailed Sentry data tagged with a version number and other metadata. Seeing quick spikes of issues of a new version at a glance is valuable data to have.