The directly linked article is confused IMHO.
One kind of "12-core" mobile CPU is an extension of the big.LITTLE concepts to have three clusters, to have a high, a medium, and a tiny cluster. You are only running one cluster at a time. The benefit is the same as big.LITTLE but more so.
Another possibility is to have 12 (or some other large number) of very little CPUs and really run them at the same time. The advantage there is you can lower the clock and voltage a lot and with CMOS that means a huge drop in power consumption. Now for the "embarassingly parallel" jobs that I do a lot of, it is pretty easy to get a near 8x speedup if you are using ExecutorService in Java (and not so easy if you are playing with Fork/Join, Actors or some other paradigm.) When you get to 16+ cores even jobs that are easy to parallelize start to hit the wall.
You might be able to get video encoding and decoding to go very wide but for common tasks like web browsing and word processing it is hard to translate a large number of cores into more responsiveness. It is an active research area and Mozilla would like to do it but it;s hard.
The SMT technology you are advocating is a different animal, the big advantage is that it is a relatively easy way to "eat" the latency that comes from the memory hierarchy. If you have a large number of instructions in flight from different threads, high latency doesn't block throughput so much. Funny enough, the most interesting SMT systems are on the server side such as Sun's Niagra and some of the chips that Cray ships these days.