What Facebook has demonstrated is that it doesn't matter what technology is initially chosen since pretty much anything can be scaled with a modicum of persistence and ingenuity. So pick what you're most comfortable with, don't worry about scaling until you need to (a great problem to have) and get going.
Not really, don't you think that there is cost factor involved here? Imagine you need to run lets say 5000 machines for you uber big app, instead of 12000, you save money, you save environment, and its usually easier to manage everything when you have less machines to care about. Costs are important. And i'm not saying that one cant make mistakes, but you don't grow facebook size in one day, but when you do grow, it's a good idea to refactor your architecture into something scalable AND FAST, before you reach the point of no return ;-) or you will end up writing your own flavour of php....
Except that by almost any measure Facebook runs one of the leanest engineering and tech ops organizations in existence.
And don't forget that the author's main thrust was that Facebook faces a "fate worse than death". Adapting a technical architecture to keep up with growth doesn't really seem worse than death, imo.
