This really doesn't matter for a large number of reasons.
First, even if applications aren't multithreaded, the operating system
and many key drivers are able to take advantage of multiple cores. The 80/20
rule applies here. If the critical 20% of the code is optimized, there will
be huge benefits.
Second, PCs don't usually do only one thing. Even if they're running a
game, you don't want the game to get laggy because some background
application suddenly found something to do. There's quite a bit of
background junk that needs to be done, and it can make single core machines
bursty.
Third, over time, more and more applications will learn to take
advantage of multiple cores. Fourth, at least for going from one core to two
core, it means an application and non-critical I/O (like disk writes) don't
compete for the CPU.
The problem is mostly programmer inertia. People do things the way they
have always done them. Fortunately, programmer turnover is high, so this
won't be a problem for more than five years at most.
The issue of massive multithreading is not quite the same as the issue
of using, say, four cores.
The case of Cell is more complicated because the cores aren't symettric
and a lot of application-specific work will be needed to get all the
horsepower out. This is good for applications like game consoles -- it can
be many years as better and better games come out that take more and more
advantage of the hardware's capabilities. Hard work optimizing 3d renderers
and physics engines is definitely on the horizon.
DS