You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked.
You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.
And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack.
NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.
Unless you use SNTP on your servers. Don't do that. Ever.
In practice, there are systems that use SNTP or regular NTP with periodic calls to ntpdate. Ubuntu does the latter, by default, and is thus susceptible to the attacks I described,
That's a bug with Ubuntu. That mode of operation is for devices without persistent real time clocks or personal laptops where time isn't that important. If you sync your time at reboots you will screw up ntpd's clock drift calculations.
This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.
You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.
And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.