> I had an extensive Silverlight and WPF background by that time, so I still don't quite know why so many developers seemed to have a problem with it.

Money on app stores is made by games. In addition to being rewritten in C# games in Silverlight had to wrap Silverlight primitives - there was no DirectX or GL ES equivalent API. There were even quite wacky workarounds for this on built in components (like render tiles to textures from some linked in C++, which are then used by Silverlight) but weren't great for anyone.

The result of this was WP7 was an island, and one which had no commercial proof of worth until it was too late. We would all be better off had WP been and stayed viable.

Relatedly, XAML shares enough low level primitives with DirectX [0] that the interop story was always meant to be smoother and it is something of a shame that it has never been particularly smooth.

It was a massive lost opportunity in UWP that DirectX never released proper, first-party WinRT components. It's still almost criminally weird that DirectX still prefers ancient COM to WinRT. I partly understand it from a backwards compatibility perspective of support old games for the longest amount of time to not just move DirectX entirely to WinRT components, but WinRT was built for forward compatibility from COM and there are and have been Windows APIs with both COM and WinRT projections.

Some of it just seems stubbornness that DirectX isn't directly usable from WinRT (and/or that "second party" projects like XNA were murdered). Certainly another thing to add to the list of why Windows Phone 7/8/10 all failed to have half the catalog of games that other systems had. (There was some DirectX in 8 and 10, but only for C++ apps. It should have played way more ball with WPF and in languages like C#.)

[0] Far more than it shares with Win32, which is partly why some die hard Win32 programmers have always disliked XAML.