You've missed the point. The argument is that eventhough aiming for FB scale is absurd, some considerations should be taken under consideration from the start. We're seeing YAGNI-style arguments being abused to sell the idea that just because it's absurd to think 10 steps ahead it's also absurd to think 2 or 3 steps ahead, which makes no sense at all.

Starting with two colos might be a good idea -- at least at the point where you start thinking of adding a second machine for data availability, it may as well be in another colo so you have a disaster recovery option.

Starting with partitioned data is a lot bigger jump. At most, I would say avoid building features that would require heroic efforts to implement in a partitioned world, but a single database can get huge these days, and maybe even huger by the time you need to scale. Chances are, 2TB of ram and 64 cores will fit your live DB needs; and if not, you'll know with time to make something else work

Sure and that’s fine, but you don’t want to have to do it when you go from one server to two servers, you know? Plan at least a little bit ahead.