You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.

I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.

The true use case here is to get you used to the idea of telemetry in your tool chain, then move the goal post further down the road. In a few years, it'll be encouraged to put telemetry in your library ("Why?" "We've already had it in the tool chain this isn't any different!") then eventually, have every application sending telemetry data to Google's servers.

If you think this is ridiculous, remember they built Chrome with telemetry embedded .. why? Not for improving services. To build better targeted advertising.

Remember Android OS? Yes.

But there's still push back and the primary group of people resisting this at large are developers and the more technically inclined.

People don’t know how many cache misses they had, or what IO exceptions and retries led to their poor experience. They know they had a poor experience.

No one will afford to make interviews on the scale of making good statistics.

It’s better to be up front with the fact that software does anonymous usage statistics and prudent that it actually is good (anonymous, and not using excessive resources).