I'd guess this minutiae was written in response to some unreferenced critique of their service, in reality nobody with sense would use TTFB as a useful measure of application performance.

In fact measuring performance anywhere near the HTTP layer is often pointless when such metrics are so disconnected from what a user actually experiences. Perhaps a better test would be something like "perceptible latency", taking into account factors like the ability for the browser to progressively render partially transmitted HTML, or large hangs as a result of external objects (e.g. web fonts, GL models, etc.), especially in a world with increasingly complex front-end Javascript blocking the browser's UI thread (syntax highlighters on blogs, anyone?).

As Apple demonstrated on the iPhone, it's more than possible to hide multi-second delays using tricks as simple as showing a facsimile image of what will shortly be loaded, similarly a web app that animates a form submit with an unintrusive 400ms animation (hiding a 500ms response time) may appear snappier from a user's perspective than an app with no animation but a 300ms response time.

Actually CloudFlare's own signup process is exemplary in this respect, they bury half minute long DNS queries in the background while the user continues filling out forms.