Hyperthreading causes two processes to share the same cpu, with fast context switching between the two processes. No additional computation resources are made available in this mode, so if both processes want access to the CPU then the two are going to contend for access, and on long term average probably each get a little under 1/2 of the work done that they would have gotten with dedicated CPUs.
The circumstances under which this kind of sharing is a gain, are the circumstances under which a CPU would otherwise be idle because it is waiting for a resource and the second process has all the resources it needs available. "Waiting for a resource" would often be waiting for I/O to finish. It might include waiting for an interrupt to occur (I do not know if it is implemented to do this). On systems with memory that is shared between a pool of CPUs, or better yet on integrated clusters with shared memory, waiting for a resource could include waiting for memory to become available from a different CPU.
A sample situation in which there would be a benefit would be if one of the threads was an interrupt handler (e.g., DAQ or GBIP input or output) and the other thread is compute bound. When the interrupt becomes ready, there could be a fast switch to the second process, service it briefly, and fast switch back to compute. Yes, you would probably do even better if you devoted a complete CPU to each thread, but the cost would be higher for that. The cost can add up a fair bit for a full context switch to have each of the two serviced by one CPU splitting the load. To invent a figure, you might be able to share a single core 96% compute, 3% I/O, 1% switching waste, whereas without hyperthreading the switching cost could be (say) 14%, leading to 83% compute, 3% I/O, 14% switching waste.
Now, if you are not doing that kind of work on all cores, if most of your cores are compute bound and not waiting for I/O or memory access, having hyperthreading on for those cores is not useful and would slow down progress; if I understand correctly, having hyperthreading turned on with an inappropriate job mix will slow down computations.
It is difficult to create the kind of guide you mention, as the benefits depend on what else is happening. Generally speaking, file operations, imread(), video decompression and decoding, video encoding, serial and DAQ can benefit -- but they might not benefit enough to be worthwhile if you have heavy computations. If you are wanting to do video encoding and decoding then an i3 processor can be a better choice than an i7, as the i3 has that capability built in (H.264 is what comes to mind.) I have forgotten whether the i5 has the encode/decode: my memory is saying that it is available either way.
