I am not sure we can do anything clever here when the network.service ends, the network is configured and up. The fact that they are not able to get to the NTP servicer is related to the infrastructure below and we can't just add "wait until you ping the server".
The easiest workaround here would be to create a timer unit, that will start the service a bit later. But anyway, there is no bug in systemd, it starts the services as expected. Let's reassign it to ntpdate to get Mirek's opinion, but I am afraid that this should be closed as "can't fix"
I suspect ntpdate is not the only service that has an ordering dependency on network and breaks if it started before the network is working.
I guess the right place to fix this would be in the network init script. It should wait for the bond interface to be fully "up" before exiting, similarly to how it waits for DHCP. I'm not sure if there is a state that could be monitored for this purpose.
Unfortunately, there is no such mechanism. So as mentioned in comment 6, this is really a can't fix.
We should consider partially reverting changes that were made for bug #1466947 (adding dependency on network-online.target).
Before that fix, ntpdate was executed several times in an exponentially increasing interval if it was not able to set the clock.
We can close this bz as another customer who reported a similar incident isn't using ntpdate anymore.
I could see other services failing at the time of boot e.g rsyslog because of bond took time to come up.
I will open a separate bug if the customer insists to fix it.