The key problem with that is having such a thing enabled by default. Doing so has great potential to harm security, even if the telemetry does not contain any user data. Shipping a development environment where it is enabled by default (which I think is what that article is saying) is inexcusable, in my opinion. Providing remote telemetry as a strictly opt-in development aid, on the other hand, is fine (as long as it is quite obvious when enabled, and the developer is given full disclosure regarding the specifics of the telemetry). It might actually be quite a useful feature for some legitimate development activities.
If an attacker gains access to the telemetry, they have an advantage. The suggestion that it can only be usefully interpreted in the presence of symbol information willingly supplied by the developer is quite likely to be false. Having access to the symbols will make it vastly easier to interpret, but the absence of symbols does not necessarily make it impossible to interpret. Exposing timing information for cryptography functions compromises the integrity and strength of the crypto.
Now, even if there are additional protections present to mitigate the risks, the risk will never be zero while the telemetry is being emitted. It adds entirely unnecessary risk, even if the risks are small or minimal and the information is difficult to use.
Finally, the simple fact that MS fairly rapidly chose to remove the functionality in an update release leads me to conclude that they recognised that there were some fundamental and serious issues with having such a feature enabled by default. Converting it into a safe opt-in feature would not have been difficult for them, complete removal of it is a fairly drastic step.
