I've been working with Win32 for about 10 years now, first using C and then C++. It is, as you rightly point out, a powerful API, but I think you also nailed it when you said "for those who strain their brains to understand it"
Is it really the sign of a good API that you have to strain your brain to understand it? Is my time as a developer better spent dealing with complexity in the API, or improving the functionality of my applications?
You say that you've "never seen something that can't be done with it" but then isn't that true of assembly language? Why are you writing in C when you could be writing assembly language - after all there's nothing that can't be done in assembler, and C adds overhead. (Overhead is one of the complaints you say you have about the .NET framework. So if overhead is that much of a problem to you, you really shouldn't be using high level languages at all, since you can only truly minimize your overheads by writing in assembly language.)
Of course the reason we use higher level technologies is that we get an improvement in productivity in exchange for the increase in runtime overheads. You have clearly already bought into this to some extent because you use C. So why do you reject the exact same tradeoff when looking at .NET?
You also say something which is, quite frankly, beyond belief: "all i find is an unnecessary complexity, obscurity"
If you really think that using .NET is more complex and obscure than Win32 then I find it very hard to believe that you've really used both. (It doesn't sound like you've even tried to 'strain your brain to understand it' even though you were happy enough to put that effort in for Win32.)
Would I be right in thinking that you've never been through a complete product development cycle in .NET? Your reaction is typical of someone who is familiar and happy with Win32 and who hasn't tried .NET in earnest yet, and has merely played with it a little and decided that it is not to their taste.
I've been using .NET for years now. (I started back in the beta days.) I still do C++ development in Win32 reasonably frequently though - sometimes my customers need code to run on non-.NET systems. And every time I have to go back to Win32, I am amazed by how much more effort it is. Everything takes about three times longer than it would have done in .NET.
(To give you a few specific examples I came across in a recent project: making an outbound HTTP request and parsing the text that came back; extracting a list of cookies from an incoming HTTP request; getting a piece of work called on a thread pool thread. All of these things are substantially more complex and more error prone in the Win32 world than in .NET. Of course you can do all these things in Win32 (or IIS) but it just takes a whole lot longer.)
And I'm not the only one who finds this - I know lots of people who work with both technologies and they have all found the same thing. .NET is simply way more productive than Win32 was. The only people I know who prefer Win32 are people who've never written a real product in .NET.
(And by the way, Win32 isn't going away. It'll be there for ever even though it will cease to be the primary API. It's just that new OS functionality will be targetted primarily at .NET applications. Win32 applications will still be able to use new features, they'll just be required to go through an interop layer to use them. But because C and Win32 have much higher development costs than .NET coding, they will become increasingly marginalized. Just like assembly language, they will still have their place, but it will be an ever smaller niche - as machines get faster, the performance benefits offered by these low-level technologies cease to justify the increased development costs.)