>> don't care how or why the API works - it just does. <<
You see, I think that is the wrong attitude. The more you know about whatever you are learning about (API in this case), the better you learn it. And if that requires learning and implementing the core API, then so be it.
As a general observation, it does take more code to write a windows app using pure API functions as opposed to using MFC. MFC wraps the Windows API with objects. I find using the CScrollBar class in MFC much easier/quicker then using API functions to achieve the same result.
However, just because a programmer decides to create some app using MFC, doesn't mean he won't be using the API. There are things that MFC simply can't do with it's classes, or it wasn't practicle to create a class for. In this case, you must use the API.
( By the way... please please please.. use the scope resoluter when you call API functions from within an MFC app).
I've found that most of the programs written where I work are written in the Windows API. We have a few MFC apps, and they are much easier to maintain, and took much less time to code.
I don't understand why people are rushing to write apps. Take your time and make an application from powerful, core API.
I have time. I want to work with the API.
Time is money. I agree that it is nice to know the API. But it is faster to get the same result using a library. This could either be your own ( unsupported, takes time to write and no-one else knows it ) or a lib like MFC.
When you work for someone else, you are likely to get paid per timeunit, being it hour, day or month. And your employer will be quite displeased if you don't get the maximum result out of the given and paid time. If you are on your own and have time to waste, then it's totally up to you what you do with it.
I think MFC code is harder to read than API code, but that's just me.