Most windowing systems have fairly specific rules about the interaction between threads and the code that (directly) manipulates a window. For most typical cases, this is handled fairly transparently by the fact that the "outside world" sends messages, and the code that handles those messages and directly manipulates the target window runs in the (one) right thread.
I'd guess we're seeing a manifestation of the same limitations here. The difference is that that OpenGL and Swing EDT expose the functionality in terms of function calls instead of messages to send. Those functions directly manipulate the underlying window in ways that a typical windowing system requires happen only from the right thread--therefore, you'd better only call those functions from the right thread.
As far as enforcement goes: at least in most systems I've seen, the "enforcement" consists of your application crashing when you do the wrong thing. If you're lucky, you might get a nice, helpful message from the OS saying you called function X from the wrong thread (though the function X to which it refers, may well be one you never called directly at all, from any thread). In the more common case, you'll get an error like segmentation fault attempting to write address 0x12345678, with no indication of what you did wrong to trigger that at all.
As to why it's done: as noted above, it's more or less mandated by underlying windowing systems. If you want to go a step further and ask why they mandate it, I'd guess it's primarily a matter of simplicity and speed. Requiring that all direct interaction with a window go through a single thread avoids dealing with concurrency everywhere. Adding all the mutexes (and such) necessary to allow multiple threads to work with it concurrently would lead to much slower development, and (probably) quite a bit slower execution as well.
