That's pretty much the summary of what I was trying to convey. It's fascinating how developers get stuck in it on one side ("we have to stick to this old version of Windows because IT has put so much work into getting it right"), but then get angry/fail to appreciate the other side ("why won't this cool new library support this old version of Windows I'm stuck in").
(The Python 2 versus Python 3 "war" is obviously very related. Sunk costs on developer/ecosystem side versus sunk costs on library/platform/language side. It's a fascinating dance that likely will always plague development.)
For what it is worth, to explore the other side, there probably were ways out of the development trap for Microsoft had they tried, and there probably are "Mexican stand-off" issues to blame and "throwing good money after bad". Silverlight (WPF/E) was meant to be a way around that standoff. I still think it was a mistake that the fork of Silverlight with desktop application support that Mesh had used to support XP and Vista was never productized. Silverlight was always meant to be a cross-platform bridge technology to WPF (and Avalon), and the .NET Core and UWP Stacks grew out of Silverlight in many respects.
The browser focus of Silverlight deployments may have been a mistake, and while Mobile realized it was exactly the transition tool they needed (using it for Windows Phone 7 and 8 while the proto-UWP was in development for 8.1 and 10), it probably was a mistake in hindsight that there wasn't a stronger "Silverlight for Desktop" option, even if it would have muddied the waters between WPF and eventually UWP. Because, yes Silverlight for Desktop could reach back to the developers stuck with sunk cost in XP or Die corporate environments (again, poor Mesh, RIP, being the poster child of that possibility), made code sharing between Mobile (Windows Phone 7) and Desktop possible/easy in the Windows 7+ transition period to Windows 8, etc.
Given Mobile seemed to recognize the importance of that transition, I'm inclined to believe that less money thrown at mobile wouldn't have helped in this particular case. Based on conversations I had at the time, my gut feeling is that some old guard C/C++ PMs had a lot more to do with the curmudgeonliness of Desktop through the transition era than the money thrown at Mobile. There certainly seemed to be a lot of distrust of any UI platform that wasn't directly developable from C/C++ and that sort of "COM or Die" Mexican standoff I feel (as mostly an outsider trying to make sense of crazy patterns, and some really bad, tangentially related interview feedback) had more to do with the rough transition to Windows 8 and UWP than Mobile did. Mobile at least tried to smooth that transition. (Arguably Mobile was in a better place to try to smooth that transition given the relative popularity of Compact Framework apps in WM 6.5, versus raw C/C++ development, but that's also a different argument.)
Anyway, armchair quarterbacking this is definitely fun, especially with hindsight and not having to actually fight any of the battles that were fought. I can very much appreciate why we are where we are at today, and yes can see some places where things could have been improved, but I also realize why they were such hard fought battles (the sunk cost fallacy is a big one that impacts most sides of all of these debates).