I strongly suspect the problem is in your code.
I created a fairly complex 'long polling' web server using the 'thread per connection' mode of MHD and it does not have this problem. I.e., many times the client makes a request and it takes 30 seconds for it to get a response. Other threads have no issues, and would not have any inherent issues with other threads 'sleeping' using any threading on any system that I'm aware of.
Unless something has changed, during initialization with 'thread per connection' mode, MHD creates all of those threads up front. They just sit idle until they need to service a connection. (At least I think that's what it does - I dug into it at one point a couple years ago.) As a result, it seems pretty unlikely you're suddenly hitting some kind of system-level thread limit when you create other threads in your application since those MHD threads don't go away once the connection is closed - they just wait for another connection.
What you're describing sounds like one of 3 things:
1) You don't have enough threads allocated for your 'thread per connection' server and clients are stalling because MHD blocks them until a thread is freed up to service the connection. (For example, browsers often open MULTIPLE connections to your server to 'pipeline' multiple requests and speed things up for the user. That causes multiple threads to be consumed.) Try increasing the number of threads in your MHD initialization and see if that fixes your problem. However, as you describe it, this doesn't seem too likely.
2) Exceedingly unlikely when using 'sleep', but it's possible the thread
scheduler in your OS is not yielding to other threads until one of the
MHD threads finishes what it's doing. I sincerely doubt this is the
case, though.
3) You have some kind of cross-threading locking mechanism that is preventing one thread from continuing while another is ongoing and/or is waiting for it to complete. Solving this is entirely application dependent - you'll just have to study how your threads interact.