title: Are there any cases when it's preferable to use a plain old Thread object instead of one of the newer constructs?
body: <p>I see a lot of people in blog posts and here on SO either avoiding or advising against the usage of the <code>Thread</code> class in recent versions of C# (and I mean of course 4.0+, with the addition of <code>Task</code> &amp; friends). Even before, there were debates about the fact that a plain old thread's functionality can be replaced in many cases by the <code>ThreadPool</code> class.</p>
  
  <p>Also, other specialized mechanisms are further rendering the <code>Thread</code> class less appealing, such as <code>Timer</code>s replacing the ugly <code>Thread</code> + <code>Sleep</code> combo, while for GUIs we have <code>BackgroundWorker</code>, etc.</p>
  
  <p>Still, the <code>Thread</code> seems to remain a very familiar concept for some people (myself included), people that, when confronted with a task that involves some kind of parallel execution, jump directly to using the good old <code>Thread</code> class. I've been wondering lately if it's time to amend my ways. </p>
  
  <p>So my question is, are there any cases when it's necessary or useful to use a plain old <code>Thread</code> object instead of one of the above constructs?</p>