The problem is that hardware has started to hit the physical limits of silicon. We can't go much denser without losing the properties of the silicon that we depend on to make the chips work. Instead, manufacturers have started to add more pipelines, cores, and other forms of parallelism in order to continue following Moore's Law. Unfortunately, application software is still a linear beast.
A few companies (notably, Google) have found ways to make application development take advantage of parallelism without introducing huge complications for the application developer. Google's search engine and Apple's Automator are both examples of applications that can take advantage of parallelism under the covers. The trick is that both are designed around a functional programming paradigm, allowing easy analysis of the application to automatically identify operations that can be run in parallel.
The article correctly expects new languages to be domain specific. Parallelism is much easier to achieve if you only need to worry about the aspects of the application specific to the problem and ignore all of the necessary cruft that allows someone (or another application) to interact with the application. The I/O might not always be parallelizable, but the core aspects that make the application unique many times can be.
We need a new language and platform for web applications. This platform should make it easy for someone to write an application that can be spread across machines and take advantage of parallelism wherever possible. This should be one of the hundred-year languages that Paul Graham writes about.