Coming from Europe, I'm a little worried by the general attitude here. We tend to side with privacy first. There are some real genuine concerns from real people like myself who have to work with this tooling. I'll detail my thoughts:
1. It's setting a bad precedence for data collection by default. Name one other tool of the same class that actually sends telemetry data home by default?
2. It's much harder to ensure that the tooling is compliant with data protection policies within an organisation if the tooling by default sends telemetry. We now have to assume it's going to send stuff by default and configure all build infrastructure, every developer workstation and every piece of the toolchain independently. This is particularly of concern in the finance sector. It also costs us time and money.
3. There's no test cases to cover the telemetry functionality at all. Check the code. What happens if it starts reporting command lines due to a trivial defect.
4. There is a crudely defined document which describes what the telemetry does, but not what it will do in the future. What happens is a PR appears, gets merged and gets pushed out to a new version. To find out what happens you have to read every merge, every PR for a release.
This is a loaded gun waiting for any security conscious team to shoot themselves in the face with. Really this will gate the product into the bin at the first technical review stage for a lot of companies. There is no appetite for being milked.
I'd also like to add the absolute zero communications on this front from MSFT. People have asked directly via PRs to turn this off because they do not want it and they have been ignored for over a year. The usual response from MSFT is never to respond directly to this question and instead outline what the telemetry does expecting the question to remain answered. If there's anything I've learned over the years; you can't trust anyone who won't answer a direct question.