So, the one regression I see possible here is on machines with lousy/broken clocks at boot time. If you start ntpd with a clock too far in the past/future, it'll either give up and exit (if VERY far off) or start a drift that could take hours/days to correct. If you remove the restarting around ntpdate, ntpdate will refuse to fix the clock (due to the socket being in use), and you're stuck either with a dead ntpd, or a drift of doom.
So, the one regression I see possible here is on machines with lousy/broken clocks at boot time. If you start ntpd with a clock too far in the past/future, it'll either give up and exit (if VERY far off) or start a drift that could take hours/days to correct. If you remove the restarting around ntpdate, ntpdate will refuse to fix the clock (due to the socket being in use), and you're stuck either with a dead ntpd, or a drift of doom.