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.
