It's hard to this do in non-technical terms (and frankly, it's not that understandable even in technical terms) but here it goes:

   -clf/-nvf

   Theoretically, it would be best to leave it to the driver to decide how to synchronize the individual kernel dispatches (calls) - this should provide the best speed and utilization of the GPU. In practice however, the driver often doesn't do very good job, and here is the role of the -clf and -nvf options (first one is for AMD cards, second one - for Nvidia cards). When these options are at their default values (1), PhoenixMiner will "force" the synchronization periodically to avoid driver issues. This still leaves some room for the driver to do optimizations between these "force" points. If the options are at 2, the driver has no say at all. The other extreme is when these options are at 0: no forced synchronization will be performed and the driver will be fully in control. Possible problems when using -clf/-nvf at 0 are unstable hashrate or semi-permanent drops of the hashrate. -clf/-nvf 2 should provide much more stable hashrate but sometimes at the price of slightly lower absolute speed.
   These options are used for both the new kernels and the old ones, and can be specified per-GPU.

 -mi

   This effectively sets the size of job performed by each kernel dispatch (call). The bigger -mi values correspond to larger kernel sizes. This usually increases the hashrate because less time is lost in overhead when starting/stopping the kernel. However the bigger job sizes can also cause crashes and unresponsive video drivers, especially if one of the GPUs is also used as main GPU (connected to a display or a plug). In most cases AMD cards have less problems with high -mi values than Nvidia cards, which are almost unusable at high -mi values and sometimes just crash with high job sizes.

 -gt

   Again, theoretically, the GPU should "know" the best how to combine the individual threads in each kernel dispatch in order to maximize the throughout. It does this by switching very fast from one thread to another whenever the first thread is waiting for a memory read/write to finish. This is something like hyper-threading on steroids. Again, the theory doesn't correspond to practice too well, so we are doing "manual" reordering of the memory accesses but this should be fine-tuned for each GPU depending on the core clocks, memory clocks, and memory access latency. This is done by the -gt parameter. Note that there may be more than one "best" or "equally best" -gt value and the difference between these will be almost 0. We are going to release an auto-tune option in PhoenixMiner 3.0, which will automatically find the best -gt values for each AMD card individually (note that -gt only works for AMD cards).