I am sure there is an impact when snoop is used in conjunction with packetd.
If I had to venture a guess I would bet it is a fairly large impact.
You can test it's affect on the sensor yourself:
Enable the 993 Dropped Packet signature. This signature will fire every few seconds or so and tell you how many packets and what percentage of packets are being dropped by packetd.
During a busy time of day on your network you would want to start up your snoop command and then watch and see what 993 alarms are being generated.
They way you run snoop will also have an affect. Are you simply capturing to the screen, or are you capturing to a file. Are you using filters or are you trying to capture everything. Each of these will affect how much cpu and disk access the snoop command will be stealing from IDS.
Alternatives to snoop:
The packetd program itself has the ability to generate binary packet logs in a libpcap format that can be read by tcpdump, ethereal, and several other freeware tools for anlysis. These logs are referred to as "iplogs".
You can set up packetd to always log packets for a specific ip address/network. So if you have a specific ip address you need to look into, then you could use this feature to capture the packets of interest.
You can also setup packetd to automatically log the binary packets for the source address of a specific alarm for a configurable number of minutes.
But beware that iplogging (binary packet logging) can have a performance impact on the sensor. You will want to use it sparingly, and limit the time of the iplogging as much as possible. Once again you can use the 993 alarm to help determine the impact on performance.
So if you are needing to produce binary packet logs, then the iplogging feature in packetd may be better than snoop logging binary packets. But if you are only using snoop to capture to the screen then snoop may be better.
The only way to know is to test in your specific circumstances/environment.
