In the case of a single-window application, Is there any reason not to process events in the main loop rather than dispatch them to the window procedure? In essence, only dispatch messages which one doesn't actually process, and then the default window procedure is sufficient?
It seems to me this would give less latency when getting input events rather than going through another pass through the kernel. This seems especially important because DispatchMessage blocks until the message gets processed in the window procedure.
Are there any messages that do not go on the usual queue that PeekMessage accesses and instead are only accessible in the window procedure?

Are there any messages that do not go on the usual queue that PeekMessage accesses and instead are only accessible in the window procedure?

Yes.

Even if there were any such messages, I'm not sure that this would be a wise thing to do. Your program should be reasonably well behaved and be able to interoperate cleanly with anything else the user has running on their machine, and bypassing the standard message routing smells like it has a high chance of failing in this requirement.

It's also the case that programs - including games - have been using standard message routing for over 15 years now. It works.

Bypassing this to achieve lower input latency is like using a thermonuclear device to crack a nut. Why not just use a low latency input API instead?

Even if there were any such messages, I'm not sure that this would be a wise thing to do. Your program should be reasonably well behaved and be able to interoperate cleanly with anything else the user has running on their machine, and bypassing the standard message routing smells like it has a high chance of failing in this requirement.

It's also the case that programs - including games - have been using standard message routing for over 15 years now. It works.

Bypassing this to achieve lower input latency is like using a thermonuclear device to crack a nut. Why not just use a low latency input API instead?

What are you referring to as low latency input API? Even getting the raw input data from a device in Windows involves getting the WM_INPUT message and responding with GetRawInputData, so all you save there is some HAL processing and there's a limited improvement in latency. More important, what I wrote in my post applies just as much to this raw input method as to standard processing of say WM_MOUSE*: you can handle it in the event loop rather than a window procedure.

In my case, I'm working with multi-touch events primarily and any latency is far more of an issue than with mouse input because it creates a very noticeable distance between the touch position(s) and whatever it is being moved/dragged, that is proportional to the latency and the speed of the movement.
I've now changed it to filter for all messages I'm interested in in the message loop and the rest are dispatched to the default window procedure. There seems to be no need to create a user window procedure if there's a single window with no controls in it that I can tell, and if one doesn't care about the specific not-queued messages that MJP pointed to. In my case my window is blank and has bound to it an OpenGL context, and that's it. Then I send input events from the message loop to the various threads that care about them using the very fast lock-free, cache optimized (write and read indices are only accessed each by one of the threads) single-producer/single-consumer buffer from http://arxiv.org/abs/1012.1824 (also part of http://mc-fastflow.sourceforge.net/ library) which I modified to store not pointers to the events but embed the events within the buffer itself, which is faster yet due to better data locality (it involved splitting the push and pop functions each into a begin and commit component, in-between which several elements may be written). This far from my testing, bypassing the message loop --> dispatch kernel call --> window procedure doesn't seem to be causing any application or system problem.