Q:

Why the same thread must be used?

In various libraries, some operations must occur on the same thread that another operation occurred on. Some examples include the Swing EDT and OpenGL.
So when something says something like "You must only call methodX() on the same thread that created ObjectY" or "The context must first be associated with threadX before calling methodY"... 
What is happening under the hood?
How is it enforced?
Why is it done? e.g. Why can't I send a command from another thread even if an object is undergoing any operation?

A:

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.

