It was. It was broken by design because it was designed for customers, not Microsoft themselves. It was designed to be just complete enough for the “demo” apps in the documentation, and no more.
The most egregious example of this that made me give up on WPF entirely is how they implemented list control data virtualisation.
Data virtualisation is when you have a list of 10K table rows and want to render only the 100 rows that’s visible on the screen. If a user scrolls through the list, there are only ever a few hundred GUI objects in existence.
In WPF, this interface was an IEnumerable, which meant that the framework was forced to iterate through 9000 items to get to 9001. You could see this as you scrolled down a long list: at some point the FPS would drop and the CPU fans would spin up.
The workaround for this required heroic efforts, something like several thousand lines of code.
Meanwhile a simple C# WinForms app could scroll through 40K rows no sweat.
Microsoft left this in WPF for years and years, telling customers that it’s “too hard” to change an established API.
They fixed it the second they had to eat their own dog food when they needed WPF for Visual Studio. You see, the compilation error list can be very long and merely scrolling through it could bring a high-end gaming PC to its knees.
I and many others in the industry decided to never write Windows GUI software ever again.