Deprecation policy

I noticed this in the framework:

    // This method was spelt wrong! Please change your code to use getCpuSpeedInMegahertz() instead
    JUCE_DEPRECATED_WITH_BODY (static int getCpuSpeedInMegaherz(), { return getCpuSpeedInMegahertz(); })

What is the juce policy about these types of deprecations?

Why even bother with a deprecation for something that the IDE’s hinting system will catch and suggest the fix for automatically?

I think anyone who is using this function would see the error, and easily fix it and not be inconvenienced by it. I feel that for simple lines like this, using JUCE_DEPRECATED_WITH_BODY is just the JUCE people trying to do the most JUCE-y solution that flexes the “we have a solution for how to deprecate code” muscle. And also steps on the least amount of toes.

So, regarding the Deprecation policy, at what point do you JUCE team people say “Let’s just make the change and let their compilers tell them via error messages” vs. deciding to wrap the function in that JUCE_DEPRECATED_WITH_BODY macro?