It's been a while, but the underlying issue is that threads aren't always one-to-one with server requests. You can have a request where some work is handled by multiple threads. Or, a single thread can do some work for multiple requests.
So one possible bug is that you have a function that implicitly depends on thread-local storage, and then you move some work to another thread and call the function there, and it doesn't work because its dependencies aren't there. You need to manually set up the thread-local storage of each new thread.
Another bug is that if a thread does work on multiple requests (say, a task queue), some thread-local storage could leak data from a different request.
In larger systems, it might even be worse: one request can be farmed out to multiple servers and then you need to pass the context along over the network when doing rpc. This only works for serializable data, but things like deadlines can be propagated, and a request id that ties it all together is useful for logging.
"Which request am I working on" is something that's transient and often doesn't map directly to OS-level objects. (Although it does map one-to-one in simple cases.)