This argument is applicable only to code that runs on only a small number of machines. Using roughly his numbers, you can afford to pay somebody US$100 000 to work for a whole year to make your code 10% faster if that code uses 100% of a million dollars' worth of hardware, which is only 200 high-end US$5000 servers or gaming machines, or 2000 low-end servers.

But that's assuming that the benefit of the speed improvement is merely improved throughput resulting in data-center savings. If the issue is that your non-AJAX UI is frustratingly and inconsistently slow and so your ex-customers have switched to your competitors' AJAX app because it has consistent 200ms response times when they click on buttons, it may not matter if their app actually uses more CPU cycles than yours (because half of it is written in JavaScript and your ex-customers aren't running Chrome yet.) If your game gets 20 frames per second and your competitor's game gets 35 frames per second with nicer-looking graphics, you're going to lose sales, even if the customers run the game for only 10 hours each.

And that's why gamer games and desktop apps are still written largely in C, C++, or Java with some Lua, and Google's large-scale apps are mostly written in C++ and Java, while small-scale server-based applications and the stuff developed by the in-house IT guys are written in all kinds of higher-productivity, lower-performance languages.