Win32/MFC/Dialog?

DialogBox creates a non-modal dialog. Dialogs use a DialogProc instead of a WndProc, which introduces a few subtle differences. (A common mistake is to not use the proper form - the compiler ought not to allow it, but many people rather believe themselves than the compiler and override the error with a cast.) A dialog does a little more - specifically, it handles tabbing between control elements. If you don't want that, then having a dialog can be quite annoying.
DialogBox creates the window from a dialog resource. This only makes sense if the window is dialog-style in the first place, i.e. lots of controls.
DialogBox doesn't let you use your own window class. All settings you would usually make there, such as the background brush, the window icon, the cursor, you have to make manually using function calls. You cannot use window or class extra storage.

MFC ...

MFC could be said to consist of two parts. But the two parts are so strongly mixed that it is not possible to say exactly what belongs to which part.

Part 1 is the wrapper. MFC provides a very thin wrapper around various handles, such as CWnd wrapping HWND, CIcon wrapping HICON, ...
Part 2 is the framework. MFC provides a framework in which applications can be written. This means usage of the document/view structure.

In both use cases, MFC will take over a lot of boilerplate code for you. The question is, of course, whether you want that. MFC does not provide an interface to the core WinAPI functionality that is any more logical than the API itself. It does provides a better interface for more complicated stuff, however. For example, ActiveX containers, which are a nightmare in plain API programming, are a snap with MFC.

MFC is powerful if you know how to use it. It can be very frustrating, too. I tried it a few times. I didn't like it. But everyone has to decide for themselves.