Potential timing attacks are always brought up in one context or the other but I don't think I've ever read a case where someone has actually executed such an attack over the internet.
It might be tempting to assume that network latency (jitter) makes these attacks impractical. This is not the case because TCP timestamps are often used by the vulnerable machines, where the precise time the packet was generated is encoded into the TCP header. No matter how long it takes the traffic to arrive, the exact time it was created is still present. Even on systems with timestamps disabled, it is possible to get an accurate idea of the packet timing by repeating the test multiple times and averaging the result to account for network jitter. So, with that in mind...
Yes, timing attacks can be done over a network. The most prominent example was a long-lived vulnerability in OpenSSH that allowed trivial user enumeration. The issue was caused by the fact that an invalid user would trigger password comparison using Blowfish, the default. When a valid user was used, SHA-2 would be used instead. While normally the timing difference is minimal, sending a large password (several kilobytes) would cause the difference to be noticeable.
From the original bug disclosure:
When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD source code. On this hard coded password structure the password hash is based on BLOWFISH ($2) algorithm. If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB) will result in shorter response time from the server for non-existing users.
Attacks against these types of bugs often exploit the fact that a different code path is taken depending on the input you provide, causing a significantly greater timing difference than is typically seen with low-level architectural timing attacks where the differences are measured in nanoseconds and come from instructions not executing in constant time (flush+flush, etc).
As the discussion on this question about a user enumeration threat based on a timing attack illustrates... timing vulnerabilities can crop up any time a different amount of work is needed to return a result, even if the rendered page is not designed to disclose the information that was used in processing the request.
The linked question refers specifically to a user enumeration vulnerability, but similar timing differences could happen in any authorization scheme that requires a resource to be fetched and permissions checked before it can be determined if the authenticated user has permission. It might be possible to discern, for example, if a user has a certain feature enabled on their account, because the authorization logic is more complex and takes longer to run.
The severity of such a vulnerability would depend entirely upon the sensitivity of the information that would be disclosed by the attack.
(By the way, this illustrates the idea: remote timing attacks might sometimes be viewed as something almost harmless, but they might play a role of a solid ground for more sophisticated attacks, build on top of other vulnerabilities and too hard to be tracked down. E.g. if at some point there will be even an apparently harmless clientside vulnerability, a timing attack may easily evolve into a severe problem.)
The reason timing attacks were always believed to be infeasible over the Internet was, basically, the round-trip time which adds a considerable margin of error, which in turn is assumed to make timing issues very obscure to a remote party. However, generally, RTT is something which, in most cases, given a good connectivity both on the victim's side and on the attacker's side (which is something too easy to achieve), statistically, is stable enough. Timing issues are also stable for that matter.
If an attacker is able to do a lot of attempts to collect enough data to do statistic measurements, they can generally make an adjustment for RTT, effectively removing this vague obfuscation of the execution time measurements. Here's another practical example of how it can be done.
Timing issues are not something to underestimate.