Except for extremely cheap embedded computers, which save a few cents by not including a battery and a quartz resonator or oscillator for a real-time clock (as a timer suitable to be used as a RTC exists even in the cheapest microcontrollers), NTP is not a major security risk, because when used in the right way it should be used just to compensate the drift of the internal RTC, which should be trusted more than NTP (for the coarse time value).
Any unexplainable discrepancy between the internal RTC and what NTP reports should be interpreted as a possible spoofing of the NTP packets and such suspect values should not be used to update the internal clock. If the accumulated adjustments of the internal clock caused by NTP exceed a few seconds per day, the sysadmin must be alerted, as something like this can happen only when either the hardware is defective or something is wrong with NTP.
Unfortunately, there are many bad implementations that follow blindly what NTP says, without checking the timestamps for plausibility. Most better implementations are still not optimal, because they just limit the time steps of the internal clock to some value e.g. to 1 second, instead of recognizing outliers in the NTP timestamps and ignoring them.
That's a valid defence, and certainly protecting against the clock being moved too far too fast is a no-brainer, but you also need to threat-model the attack: what are the chances of an real attacker (not a theoretical weakness) carrying out an NTP-based attack and what would they gain from it? For example an attacker who has control over your local network and can spoof NTP on it, which means it's probably already game over before you even start, can move the clock on something around and reuse an expired certificate if they've compromised the device and captured its private key... you can probably dream up some sort of scenario where this might be an issue and where all the other things they can do with that level of compromise of the system won't be easier but it's so far down on the list of other things that attackers could do that it doesn't even rate.
And for the few places where clock distribution is critical, e.g. when you need to use IEEE 1588 PTP (Precision Time Protocol) you're typically running over tightly-controlled private links/networks or protocols (IEC 61850, 62439) and/or using GPS or rubidium clocks as your time source, not NTP. Or you sync using nonces, not time. Or whatever. It's just really hard to come up with a real-world scenario where this is a significant threat, and moreso one where the answer would be to run NTP over TLS rather than just using some better mechanism for the job.
NTP failure and clock drift on a home router with DNS-over-HTTPS results in total denial of (DNS-based) internet access due to DoH certificate validity, for example.
Any unexplainable discrepancy between the internal RTC and what NTP reports should be interpreted as a possible spoofing of the NTP packets and such suspect values should not be used to update the internal clock. If the accumulated adjustments of the internal clock caused by NTP exceed a few seconds per day, the sysadmin must be alerted, as something like this can happen only when either the hardware is defective or something is wrong with NTP.
Unfortunately, there are many bad implementations that follow blindly what NTP says, without checking the timestamps for plausibility. Most better implementations are still not optimal, because they just limit the time steps of the internal clock to some value e.g. to 1 second, instead of recognizing outliers in the NTP timestamps and ignoring them.