I believe that all three possibilities have different use cases. QtConcurrent and QThreadPool are more task-based whereas QThread is, well, a thread.
QtConcurrent provides easy access to put single functions into a multithreaded environment. I think it even uses a thread pool in the background. QtConcurrent is especially helpful in the context of the map and reduce operations. With QtConcurrent::run() the idea is just asynchronous execution. If you have short tasks you can use QtConcurrent.
The QThreadPool has two advantages over plain old threads: First, you don't have the thread creation cost if you spawn many short lived threads. And second, it helps avoiding oversubscription of CPU cores. In that sense its use is similar to QtConcurrent::run(): it is best utilized for short lived tasks.
If you want to a have a thread permanently running, QThread is your only reasonable choice. My preference is to use the default implementation of a thread and have it run the event queue. Then, I can use QMetaObject::invokeMethod with the thread as its first parameter to queue some work into that thread.
That all said: You should think twice if you really want to go down this route. First of all, it is a hassle to manage the GUI correctly from a separate thread as all GUI calls need to be inside the GUI thread. If you don't have a performance problem with your software, don't use additional threads. It has a non-negligible performance overhead. This is fact might introduce performance problems on its own. Furthermore, multithreading is prone to additional errors and bugs. This last argument is why you should avoid threads if they are not necessary for your performance.
