Here's an exercise -- think of your favorite or your most frustrating desktop applications. Maybe a browser, a mail reader, presentation or drawing apps. No matter which specific application comes to mind, that application almost certainly consists of long stretches of sequential code. Almost certainly a good bit of that code could be concurrent not in the sense of a parallel algorithm, but in the sense of there being no logical reason for C to follow B to follow A other than the languages used reinforce that style.
Anytime time you see an hour glass, you see an opportunity for concurrency.
I've been trying out Yahoo's beta email application. It's fine, but really cries out to be developed in a truly concurrent system. Moving more applications into an environment worse than modern desktops, let alone far from securely concurrent, is just a shame. Modern browsers are horrible platforms. We need a new browser model that is concurrent and secure. We need a new desktop that is concurrent and connected.
Both the desktop and the browser are poorly suited for upcoming many-core laptops and desktops. Not to mention five or ten years from now when we may well be deluged in so much more cheap iron looking to do something useful for us other than running bloated sequential code.
Programming shared memory threads in C# with transactional memory will not get us any closer to where we need to be. We need to think much differently with languages that support that thinking. It's only too bad we're still in the 1970s.
Tony Hoare developed monitors in the early 1970s then replaced them with concurrent message passing in the late 1970s. Then Java brought us monitors again in the mid-1990s.
Over a decade later we're still twiddling bits in critical sections stuck in a stretch of sequential code. It's ludicrous to think that's the natural human problem solving model. The tools have shaped our thinking. And I am rambling.