My point was that user interface patterns do not always indicate the importance of the control, because there may be multiple modes of operation (such as "Standby", "War", "War Game", and "Readiness Drill") that might not be obvious--or even apparent--from the raw button-press numbers.

You want the "War Game" telemetry to count for the "War" design, but you can't really tell which is which without having additional data that you shouldn't be allowed to see. If you detect "casual user" and "programmer" modes in your OS, the user shouts, "I don't want my computer knowing (and sharing) that much info about who I am!"

Even though most people aren't likely to ever need to use a fire extinguisher, you really want that interface to be simple and accessible. If you decide that because no one ever used this particular fire extinguisher, it doesn't need to be there, that's a decision that could make the difference between life and death. Moving a button on a form doesn't seem quite that serious, but it could still cause people to lose time or money, which adds up across all the people using the software.

But they aren't saying they will blindly follow the telemetry data, just that it's an important factor.

You need to determine which feature to add:

1. One that 3 developers asked for

2. One that 6 developers asked for.

With telemetry that can become:

1. One that 3 developers asked for and can improve things for 60% of your userbase.

2. One that 6 developers asked for, but only 12 of them are using the function that it will improve.

Without telemetry data, you are playing with an arm tied behind your back.