Given that PowerShell is Open Source, you can exactly see the telemetry code. Before we added the first bit of telemetry or when we needed to add more, we published RFCs for community feedback disclosing what we were collecting and why. https://github.com/PowerShell/PowerShell-RFC/blob/master/5-F... and https://github.com/PowerShell/PowerShell-RFC/blob/master/2-D.... We recognize that some users don't want to send any, which is why we made it simple to disable (completely!). However, opt-in telemetry also means we would receive very little making it not useful. Before any telemetry is added, we also go through an extensive privacy review to ensure no personally identifiable information is included (therefore all our telemetry is anonymous).
The average user cannot be assumed or expected to be following powershell blogs or to have gone through the community discussions or to have read the RFCs and definitely not to have individually reviewed the source code, they would just download and run powershell while not being aware that this functionality even exists and be dismayed once they learn about it. In this onboarding scenario the current form does not even satisfy good faith disclosure criteria much less can be said to constitute an informed consent.
A trustworthy way to do this would have been to have the user presented with a prompt upon first interactive run explaining them the importance of the telemetry to msft with a link to relevant documentation and privacy policy and a Y/N selection, anytime the collection logic changes or a new datum is added the consent needs to be renewed, and if it turns out that under those conditions most users choose not to enable it than it will probably be the single most actionable user input msft receives from/about its telemetry practices.
