But if you have a dynamic webpage, TTFB measures how long it took you to process the page and start outputting results. The rigged server in this test doesn't seem relevant to that case, or am I missing something?
When using a dynamically generated page it is possible to send the HTTP headers, then maybe send some some content and then do some server side calculations or database access, and finally send the rest of the page content. The TTFB measured by the tests, which were mentioned in the article, will not reflect the time needed for server side calculations.
When using a server side scripting language there may be some kind of output buffering, which has to be deactivated first.
This is because when sending the response you need to know the HTTP status of that response. Is it a redirect? And if you're querying the database lazily, after your page started to render, what about DB errors that could happen? Then you'd need to send an HTTP 500.
This is the drawback of using this feature in Rails 3. You have to ensure that there's no way something unpredictable happens. And you have to activate the feature explicitly in your controllers. And after you did that, you're probably going to be aware that TTFB is not that relevant.
The problem is not with TTFB -- it's that tests that succeed even with "cheating" header responses need to be fixed, if possible, to fail the cheating server.
WebPageTest could modify their TTFB test to require a complete header, so the single-character cheating wouldn't work.