Tread vs ThreadPool

The main difference is whether you manage the thread lifetime yourself (Thread), or you take advantage of the "pool" of threads the framework already creates.

Using ThreadPool.QueueUserWorkItem will (often) use a thread that already exists in the system. This means you don't have the overhead of spinning up a new thread - instead, a set of threads is already there, and your work is just run on one of them. This can be especially beneficial if you're doing many operations which are short lived.

When you use new Thread, you actually spin up a new thread that will live until your delegate completes its execution.

Note that, as of .NET 4 and 4.5, I'd recommend using the Task and Task<T> types instead of making your own threads, or using ThreadPool.QueueUserWorkItem. These (by default) use the thread pool to execute, but provide many other useful abstractions, especially with C# 5 and the await/async keywords

.
The BackgroundWorker class is an abstraction over the thread pool. It uses the ThreadPool to queue up "work" (your DoWork event handler), but also provides extra functionality which allows progress and completion events to be posted back to the initial SynchronizationContext (which, in a GUI program, will typically be the user interface thread). This simplifies tasks where you want to update a UI for progress or completion notifications as background "work" is running on a background thread.