As a rule of thumb, anything above about 100ms has perceptible latency to end users (even if they're not consciously thinking about it, they're noticing it). Depending on your application, and how captive your users are, you may or may not care about this perception. If you're taking users through filing an insurance claim, you don't, because your users can't go anywhere. But if your users are filling a shopping cart, or paying for content with their attention, you care a lot more, because lag eventually bounces users from your site.
Further, there are features that aren't really tenable unless you get lag under control (somehow, either by eliminating it or by taming it with cashing, prediction, and interpolation). Game servers are everyone's canonical example here, but really any kind of real-time feature fits the bill. Now, most CRUD applications don't have real-time features, so this might not be a big motivator. But one subtle bet we're making is that more apps would do interesting real-time things if it that latency problem was easy to solve.
The big problem you have if you're working on these problems is that it's very difficult to fit into this kind of latency budget if all your stuff is hosted in Loudoun County, because the speed of light is eating most (all?) of that 100ms.
That's the logic of wanting to get deployed in multiple cities simultaneously. There's more than one way to do it! We're just one possible solution.