Once upon a time multi-threaded programs were for clever programmers, or at least programmers who thought they were clever but, as is the way with such things, their programs generally didn't work as they expected...
Parallel programming is hard but since the introduction of multi-core processors every programmer has been subject to an increasing pressure to write multi-threaded programs. This is due in part to the original reason that "clever" programmers used threads to make their user interfaces more responsive. The simple background worker thread pattern was even made available as part of the .NET framework and taken up by Visual Basic programmers. Indeed multi-threading is almost essential for applications using the replacement for Windows forms, i.e. WPF, as it doesn't encourage the use of cooperative multi-tasking as typified by the "doevents" command.
However the really big pressure to go multi-threaded is all down to the increasing availability of multi-core processors. A dual-core processor can actually run an application that uses two threads, correctly synchronized and implemented of course, faster than a single-threaded version of the same. If dual-core processors provided the promise of, in theory, doubling the speed of code then how can we resist the lure of the new AMD Opteron 6100 range with from eight to twelve cores per processor. This, for the moment beats Intel's latest Xeon 5600 with its six cores but past history suggests that the gap will be temporary.
The new AMD processor also makes quad-processor (4P) machines potentially as cheap as dual-processor (2P) machines. The 6100 Opterons will work in 1P, 2P or 4P machines with no price premiums. So in principle you could start to think in terms of running your application on machines with twelve to 48 cores available. Until quite recently only specialists in the field of parallel processing had the chance to write programs for arrays of 48 processors - now we will all be expected to do it.
One thing is very clear - if we are going to take advantage of such large numbers of processors we are going to need some tools that are much easier to use than threading libraries such as Intel's Threaded Building Blocks (TFF). Currently technologies that are worth watching include Intel's Parallel Studio and and Microsoft's Task Parallel Library (part of .NET 4.0).
The bottom line is - like it or not - we are all parallel programmers now.