What (multithreaded?) alternative approaches are there to the "main UI thread" event loop scheme?

Question

I'm conjuring up my own UI framework and have a window in which I can draw stuff working on Windows and Linux. This means I call xcb_wait_for_event or GetMessage to process window related events (such as resizing or closing of a window). Most, if not all GUI frameworks I know work with one of these event loops that process all application events in a dedicated event loop thread.

In contrast, just because I could, I have each window running its own thread with its own event loop. On both OSes this works just fine. This is opposite of what everyone else does. I wonder if there are any proper descriptions of how this approach can best be filled in. All I read is that multithreaded UI is the devil and a main event loop "UI thread" solves so many issues. I just never find an explanation or even a proof of concept of the "bad" way, i.e. no "main" event loop thread. Hence also no demonstrations of any of the so many issues this approach apparently causes.

I understand that at least in the case of Apple OSes I'm lightly screwed as their native frameworks have a hard "main thread" requirement baked in. Let's forget about that detail and concentrate on the layer above (a multithreaded UI framework that abstracts away the OS layer). What precisely is so difficult or impossible to do with a truly multithreaded UI? As far as I can tell, the OS (or xcb in case of Linux) does quite a fine job of synchronising the UI stuff, and it provides the necessary functionality to actually write a multithreaded abstraction for the UI.