My experience is with ntp rather than openntpd.
You should know that the NTP protocol usually starts with sending packets every minute (64 seconds), but usually settles in by sending and receiving one packet every 17 minutes for each server you have in your /etc/ntp.conf file. Network outages or an unstable clock in your device may increase this, however. Each packet has a payload of about 68 bytes, so that's probably a little more than 100 bytes, each way, per poll.
The rdate and ntpdate at network up time are good ideas for setting the time. And if that is all you need should work well for you.
If you need to keep the time in sync over an extended time, however, the ntp protocol was designed to do that. The clock in your device will run a little fast or slow depending on how warm or cool it gets, even though it probably has a crystal controlled clock -- and ongoing timekeeping is meant to adjust for that.
Here are some suggestions if you need ongoing timekeeping and wish to reduce bandwidth used. They refer to items in ntp.conf.
Don't use iburst. (But it will take more time to set the time initially).
Increase minpoll upwards from 6 (2^6 seconds is 64 seconds). This reduces traffic when the protocol starts up after the network comes up.
Increase maxpoll upwards from 10 (2^10 seconds is 1024 seconds or about every 17 minutes. You can go as far as 17 to poll about every 36 hours. I haven't tried this myself.
Use only a minimum number of servers, if you had one that can be reliably reached from your embedded devices, that would have been great. The more servers the more reliable the timekeeping can be, but traffic scales up, so it is a trade off.