Win32 uses messages for everything. While Windows does include signals[0], only three are actually used (SIGABRT, SIGFPE, SIGTERM), and in practice I don't think I've ever seen a Win32 program implement signal handlers.
I find Win32 vastly superior than UNIX in this area.
Someone correct me if I'm wrong, but because of the way the syscall callback operates, it could be interrupting threads at almost any stage. This makes executing the signal in a safe manner very difficult, and from the signal handler itself you can only run certain code. If i remember correctly, most signal handler implementations then get reduced to basically set some state and return, where the regular execution will then check for that state and react to it. Well, if your only going to process the signal during you main event loop anyways, then why not just exchange the information over a message queue, and send a message to the process when you want it to do something (ie reload configuration).
It sounds like a necessary use case to me. While most people would probably not use it, that doesn't invalidate its existence. Most people would probably not touch any low level code either way.