The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL).
With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.
Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components.
From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time.
These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.