Through the BCL Website, Gheorghe Marius enquired:

Why can't we set a thread priority to TIME_CRITICAL. from managed code ?

We don't allow TIME_CRITICAL, or IDLE. The CLR will use the current thread to perform an assembly load, a type load, JIT a method, perform a GC, execute a class constructor, etc.  If that current thread has a TIME_CRITICAL or IDLE priority, these infrastructure operations would execute under that priority.  We could fix this, though I don’t know the cost of doing Get/SetThreadPriority around all these operations.

We didn’t support these values initially because we wanted to be conservative and because we didn’t want to chase all the places where we “steal” execution on an application thread.  If there’s a customer need, that would influence our decision. 

The workaround is to PInvoke to SetThreadPriority.  However, there’s some danger that this setting will decay over time.  I glanced at the code and it looks like we will revert any ThreadPool threads back to NORMAL during certain pathways through a GC.