The article you quote applies their latency system on SYN packets, the first step of a TCP handshake. For the attacker, SYN flood attacks are attractive because they work well with IP spoofing: since the attacker does not need to see the response packets from the server (the SYN+ACK), then the attacker can use a fake source address, and thus remain "hidden". None of this really applies to a Tor hidden server, because, by definition, the attacker cannot know the true IP address of the server. Indeed, when accessing a server through Tor, any client talks to it only through several successive routers, and the router which actually talks to the hidden server will not be the attacker's machine (or, at least, so we hope) -- thus, no SYN flood.
(Or, more accurately, an attacker can SYN flood any Tor relay node, but cannot know which relay node is actually his specific target site.)
The principle of latency might still be applied, at a higher level. It exists in the case of emails; this is called Greylisting. Upon first connection, the email sender is being temporarily rejected, and informed that it should try again later on. Only if it comes back after a few minutes (or hours) then the email is accepted as genuine. This assumes that the spammer won't allocate resources to remember the email sending, thus won't come back.
Translated to a Web context, this would take the form of a special HTTP response "come back later" which would include a secret token computed by the server, to be included in the response, so that the server knows that it is "the same client" than previously. Doing that without allocating too much memory on the server can be tricky (encoding dates, counters and a MAC in the token can help). However, a big issue remains: this system needs client cooperation. We cannot rely on the attacker for cooperating...
Latency-based systems work as long as the server can know when a given client is coming back, but also when this is a new client. This must work both ways: a returning client must be able to prove that it is the same client than previously (the "secret token" alluded to above can do that), but it must not be able to masquerade as a whole new client when it is actually a returning client. The privacy features of Tor effectively prevent that. Indeed, if any connection could be unambiguously identified as "new client" or "same client than previously", then client tracking would be too easy.
Thus, we can say that Tor is indeed incompatible with anti-DDoS systems which rely on client tracking, including latency-based system.