That's exactly the problem. Raw Win32 doesn't really have provisions for layouting containers and auto-resize behaviour. So you'd essentially have to handle WM_SIZE and reposition/resize all controls in the dialog. Such code is cumbersome to write, awkward to change and annoying to debug/test (e.g. you still need to check that you don't change something to negative sizes and/or constrain the window dimensions appropriately). And in the end you have a few hundred lines of code that are intricately linked to the current dialog layout and, in part, even replicate the layout. So you cannot even easily change the layout anymore. This is quite a bit of a cost associated with that.

Inventing layout containers on the Win32 side seems a pointless idea as well, considering that nearly no one except Microsoft actually uses the API at that level, so improvements here have little benefit for lots of work. Most people most likely use wrappers around it that offer such things (e.g. Windows Forms), or things that take care of their own rendering and offer layout containers (WPF, Swing, GTK, Qt, ...).

So I guess if MS offered the usual layout mechanisms in Win32 people would just shrug and ask »Why? I already have those things in the toolkit I use. Can't they devote development resources to actually important things?«.