The trouble with Windows comes down to new installations of old software on new operating systems. You can't deprecate anything, because some 20-year-old binary might schlep its way onto a customer's Windows 10 box, and they'll expect it to work.
(The real key to fixing this would be layers of frozen-in-time compatibility sandboxes, allowing code written in 1995 to get a 1995-era synthetic environment, while the frameworks of today can forget about 1995. But that means dropping the ability to fix security flaws in any of that old code; or extend it with accessibility-device support that didn't exist back then; etc. The choice is obvious, and yet extremely unpalatable as well.)
You can still mark it deprecated, even if you don't actually get around to removing it - code that gets recompiled will see the warning and hopefully fix it, and that which doesn't will still work.
2. to enable rearchitecture or refactoring that can't take place with a function of the old style "in the way"; and
3. to reduce maintenance burden.
Indefinite deprecation without removal helps with #1, but doesn't aid either #2 and #3βand without those additional benefits, usually there's no point: if you're going to be maintaining the function in perpetuity anyway, and won't be able to change the framework out from under the function, then people may as well keep using the function.
Keep in mind, also, that "deprecation" can't do much to control Windows developers; they make full and willing use of even private APIs, raw writes to private registry keys, etc. whenever they find them. Microsoft tries to keep compatibility even with these programs. With such developers around, deprecating a feature doesn't change much; as long as it's there, and calling it works, people will continue shipping code that calls it despite the warnings. They'll even write new code that calls it.
And a third argument: sometimes Microsoft deprecates a particular API for accessing some functionality, and doesn't go on to provide any alternative API for that functionality. And this isn't a case where they're saying "you just shouldn't be trying to do that any more"; these are cases where there is MSDN documentation that tells you how to idiomatically do something... by using a deprecated function. This taints the "reliability" of deprecation as a useful signal for Windows developers.
Those three effects together mean that Microsoft mostly just doesn't bother. Instead of trying to evolve APIs at all by deprecating old features and then refactoring the API surface once the old functions are "out of the way", Microsoft simply write entirely new APIs, leaving the old APIs in place. The old DLL is still there, and still maintained. It might sometimes have been hollowed out into a shim wrapper that calls into the new API... but it's very unlikely, because that destroys "bug for bug" compatibility.
(The real key to fixing this would be layers of frozen-in-time compatibility sandboxes, allowing code written in 1995 to get a 1995-era synthetic environment, while the frameworks of today can forget about 1995. But that means dropping the ability to fix security flaws in any of that old code; or extend it with accessibility-device support that didn't exist back then; etc. The choice is obvious, and yet extremely unpalatable as well.)