Lots of automation executes on a schedule. If you control time, you can cause something to happen (or not happen) as you like.
Use your imagination. Don't forget to combine this with other attacks - if you compromise something your target talks to, for instance, or with non-technical actions - shorting a stock, maybe.
More generally, the two major assumptions that a lot of complex systems depend on are time and identity. There are a lot of games you can play controlling one of those. (Controlling both is better, of course.)
Say you've gotten your hands on an old, expired TLS certificate (or cracked one using old crypto). Then, if you can convince a client it's in the past, you can use that to mount an attack.
Tor has a related problem where the Tor consensus is only valid for a specific time window - if you use the consensus outside that time window you may end up using a completely different set of nodes than what everyone else is using, potentially greatly reducing your anonymity.
For most crypto applications like certificate expiry, you don't need a particularly accurate clock - +- a day or two is fine - but with Tor the devs have to balance being able to frequently update the consensus with clock accuracy; IIRC the maximum allowable clock skew in Tor is about six hours.
Of course, note how even in that case, if user-experience wasn't an issue you'd be better off telling the user to just look out the window to set their clock than using Roughtime. :)
Use your imagination. Don't forget to combine this with other attacks - if you compromise something your target talks to, for instance, or with non-technical actions - shorting a stock, maybe.
More generally, the two major assumptions that a lot of complex systems depend on are time and identity. There are a lot of games you can play controlling one of those. (Controlling both is better, of course.)