I think if you expect to be under 60K/s and suddenly find yourself at 20K/s heading for 200K/s-- you have a better problem than if you built for 1M/s and actual load is 20K/s. The unexpected success of the former will pay for a lot of band-aids and scaling, while you're pretty stuck with the cost structure and upfront spent capital in the latter.
IMO one should design for actual anticipated scale with moderate margin, only exceeding this when it's relatively "free" to do so. (If you can buy bigger hardware for a few K, or if solutions are equivalent other than scalability, pick the bigger solution).
This is conventional wisdom, but I wonder. Labor is a material cost against most software businesses. Doing the Whatsapp thing where you just make extremely good choices upfront so that you can reach $10B scale with hardly any employees or infra footprint seems like a pretty good deal for the founding team. Plenty of other 2010s darlings are in structural trouble with stock-based comp because they are locked into these insanely overcomplicated architectures due to bad decisions from the startup and hypergrowth phases + path dependency.