The prescription about number of threads has nothing to do with the logic of your application. It may well make sense to have MANY more threads than cores in your application, regardless of whether they are compute bound, or I/O bound.
The reason for the prescription is that when you have more compute bound threads than cores, the extra compute bound threads will be waiting, and not making forward progress on their computation.
Consider having T=20 threads, and C=8 cores. Consider your run-q (the list of available threads to run). At most 8 can be running, and the rest will be sitting around in the queue waiting for their chance to run.
If a large percentage of your threads were I/O bound (or blocking on anything really) - then they won't be 'ready to run' anyhow, and won't affect your CPU utilization.
If you think of the job of your application is to keep all the CPU cores hot (running fully at 100%), there is no gain in CPU utilization by adding more compute intensive threads after you have at least enough (compute intensive) threads for each (logical) core.
NOTE - thats the thought process behind this theory (and probably the blogger). It's really not quite true. There are MANY more factors that come into account in deciding how to get the most compute out of your processor. One consideration is that it SLOWS DOWN each core to have all the cores operating. So EVEN up til the point where you have enough compute threads for each core, adding more compute threads can slow you down as much as speed you up.
And there is significant CPU overhead in managing the threads (and can be memory locality issues, depending on how you allocate/manage your threads).
So - personally - I'd advise worrying less about this sort of reasoning, and more about the logical structure of your application - what makes sense for it and how to make it work. Use thread pools. And make their sizes configurable.