The old adage "if all other things are held equal" applies here. It does get more complicated when other things can't be held equal, as you've pointed out.

There are actually a number of issues with the continuation of Moore's Law. You've pointed out two, but things like current leakage at such small sizes requiring research into different substrate materials altogether come to mind as well. The very fact that tighter spaces mean less forgiving clock variances is one to consider. That's very similar, if not the exact, problem that bit AMD recently with the bugs in their initial Phenom and Barcelona-core Opteron releases.

The world's starting to scale programs out rather than just up in response to these difficulties. It would be wise for us as programmers to work on optimizing those programs that really need it by using more of the hardware that's available rather than counting on faster individual threads of execution to roll around. Threads, forked processes, clustering, and all manner of IPC and communications need to be considered. It's a whole new world of how programs will be written for performance, and the "faster processor next year" mindset is wholly outdated in it. Soon, we might be talking about optimizing programs for minimal state passing between disparate hardware nodes vs. installing more servers in a rack instead of optimizing for a single processor vs. buying a faster processor for many applications.

There is hope with materials science and electronics research, like germanium arsenide, gallium arsenide, graphene, and spintronic storage for Moore's Law to continue for some time. However, scaling hardware both up and out instead of just up has made it all the way to the desktop already.

Unless we're ready to, as programmers, resign ourselves to more programs running at modestly faster speeds rather than making single programs run leaps and bounds faster, then we need to keep in mind that concurrency really does matter.

As Perl programmers specifically, we need to be working on getting Perl to support many kinds of concurrency and how to use that support to our advantage. Perl6 has many things that may be implemented in a way that supports concurrency better than Perl5 does, such as hyperoperators, explicit support for coroutines, and stronger support for serialization/deserialization of data and code to name a few.