When the attack was first described in 2003 (the "bad padding" oracle through timing analysis), the intended attack scenario was an email client (e.g. Outlook Express) which connected regularly (e.g. once per minute) to the server to know whether some new mail has arrived (you cannot be notified of new mail when using the POP protocol; you have to poll). Since each connection would begin with the same authentication phase, the target password being at a deterministic, reproducible emplacement in the stream, and since Outlook Express is notoriously bad at error reporting (i.e. it is either silent, or it just updates a long-standing error popup which the user has been trained to ignore), then it was a good setup for the attack.
An important point to make is that such attacks must occur near the decryption point, where the "interesting data" (the password) is about to be decrypted. In the mail server scenario, this is near the server, not the client.
The "Lucky Thirteen" adds two new data points:
It points out that the common defense against timing attacks (namely, when the padding is wrong, act as if it was good and compute the MAC nonetheless) can leak a bit (because the "assumed padding" does not have the exact length of the "good padding"). Where the initial attack of 2003 used delays of about 1 millisecond, the new leak is about one thousand times shorter, about 1 microsecond.
It demonstrates that in lab conditions (100 Mbit/s ethernet with only one switch between target and attacker, millions of measures) measures down to about 1 microsecond are feasible.
The first point is of course interesting. I would claim, however, that the second point has this fundamental flaw: if the attacker can get this close to the target, then he can win in many other ways. Indeed, timing attacks are about extracting information from a closed system through time-based data leaks. We cryptographers tend to concentrate on the cryptographic layer, because that's our job, and cryptography is all about concentration of secrets: the "key" is the essence of secrecy, and a very valuable target. However, the whole point of encryption is to protect sensitive data and any processing of confidential data can leak some of it through timing.
In a complete data processing stack, the SSL/TLS layer stays between the low-level TCP/IP stack, and the "application" which uses the confidential data in various ways. Since decryption occurs in TLS, the TCP/IP layer sees only encrypted chunks and thus has nothing to leak. However, it would be overoptimistic, verging on the preposterous, to believe that leaks may occur only in the TLS layer. The complete application code is potentially as vulnerable to timing attacks. While an attack on TLS itself is more newsworthy, I claim that attacks on the application code are much more likely to be devastating.
To sum up, the "lucky thirteen" attack is interesting but not very realistic. With regards to timing attacks, the TLS layer is only the tip of the iceberg. To abuse the metaphor a bit further, worrying about the "lucky thirteen" is a bit like worrying about corrosion on board the Titanic: a valid concern in an abstract sort of way, but not as pressing as other issues related to boating.