It certainly does have implications to watch out for. It's irritating, though it's a relatively special case.
AF_PACKET is a privileged operation. This means it's not something your unprivileged users can get into trouble by using.
Software that uses it will be similar to a DHCP server - low level network infrastructure - otherwise it would be able to use the normal, simpler interface. As a sysadmin, you will surely know if you have installed a DHCP server. The same would apply in some other cases as well.
1. firewall with different zones
It's possible you define a firewall with multiple "zones" or similar using iptables, e.g. on a Linux box acting which acts as a firewall between your network and the internet. In this case, since DHCPD etc bypasses this firewall, you must indeed configure your policy into DHCPD etc separately. E.g.
If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:
# Command line options here
This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.
AFAICT, there is not any finer grained option for ISC DHCPD. If you wanted finer grained control, you would have to implement this at the network level... while using DHCP relays of your choice which do provide more fine-grained control. Since the initial DHCP receiver needs to be on the same network as the DHCP client. As pointed out by Hauke Laging, a Linux server is capable of creating virtual networks in a number of ways, e.g. it shouldn't be necessary to resort to a physically separate firewall box unless you really want to :).
2. Packet sniffers
You're supposed to be terrified of running the Wireshark packet sniffer, because it's running a whole bunch of parsers written in a memory-unsafe language. And the traffic it receives won't be limited by the firewall. https://wiki.wireshark.org/Security
3. outgoing firewall
It's slightly ambiguous, but it sounds like your test program sent a packet which would have been blocked by your iptables firewall. I.e. you are filtering outgoing packets.
This is not the most common configuration. This question doesn't seem to be super specific about the threat model being used, and why this uncommon configuration is being used, so I'm not sure what advice I can give.
If you run a program with privileges that include CAP_NET_RAW then yes, it has the ability to send packets which are not affected by iptables. But equally, if you run a program with privileges that include CAP_NET_ADMIN, it has the ability to install an iptables rule which allows it to send whatever packet it wants :).