If a client makes 50 requests before the cache expires, then those will all be based on the cached result.
This is still efficient enough that there's probably no more than a single DNS hit for every web page load, even with a short (say, 5 second) TTL, because most web assets will be loaded within that five second window. (If your web page takes longer than 5 seconds to load, you have far more significant issues than a few UDP DNS requests.)
Whether the list of invalid use cases are straw man arguments are left as an exercise to the reader, but this article seems to be arguing only one side of the perfectly valid trade-off between flexibility (low TTL's) versus latency (high TTL's).
In other words, if high TTL's are so great and there's no compelling reasons to not use them, why not make them one year? Ten years?
On the other hand, many (probably most) applications can probably absorb a five-minute outage without anyone screaming too loudly.
Clearly there is a balance between "long" and "short" (probably somewhere between one second and infinity). It's good to think about these things and optimize for lower latency, but if five-minute or longer TTL's simply don't fit your use case, then don't feel bad about it.