I think the idea is that NTP is only supposed to work if your clock is close enough to correct, in order to prevent wackiness from ensuing due to sudden extreme

I think the idea is that NTP is only supposed to work if your clock is close enough to correct, in order to prevent wackiness from ensuing due to sudden extreme jumps in the system time, presumably from a misconfiguration, compromised server, or whatever. I suppose you could just rely on an insecure NTP and force the date correction, but given that the default is not to do that and you have to force it, there’s probably some reason why you shouldn’t. So, if your goal is to get the accurate time over a secure connection, getting a “close enough” time over an insecure connection and confirming/adjusting the time over secure NTP doesn’t actually seem like the craziest way to do it. I don’t really know why bootstrapping over HTTP then adjusting via secure NTP is better than bootstrapping via plaintext NTP then confirming with SSL enabled, but I guess it at least means two servers and protocols would have to be compromised.