It makes sense to me that /etc/init.d/iptables should have some awareness of applications that depend or are impacted on it and ntpd seems to be just such a case. The list could be long expect the keepers of iptables to not want to open the door to a flood.
This looks like a layer problem to me. iptables is really a low-level tool for implementing firewalls, yet it's treated like high-level service by the initscripts. There are also a lot of high-level firewall systems like shorewall and fwbuilder that replace the low-level service provided by the iptables initscript. None of these would be aware of the "manual" hole-punching that the ntpd script does.
If we need network services to have the ability to request holes, we need some common scheme to communicate this among all the many possible participants. For instance, we could have a directory /etc/sysconfig/firewall-requests where packages like ntpd can drop their requirements in a neutral specification language. Any firewall package can parse this directory and modify its rules accordingly.
(BTW, the DHCP client has a similar issue: DHCP can supply many configuration values, and currently the client only runs a single script to manage them all. A better solution is a directory of scripts supplied from different packages.)
