Usually this is discussed in the context of network capture appliances. So - for example - if you have taps on four links and a given packet happens to traverse all four then you'll naturally see four copies of the same packet. De-duplication is the capability to deliver only one copy of this packet to a protocol analyzer.
ETA: Some actual use-cases might help to illustrate both the need and the function better. Imagine a classic enterprise network that consists of dozens of switches organized into a series of core, aggregation and end-device access switches. A few of these switches might connect to the firewalls and routers that go to the Internet while others connect to a WAN and others still are for servers and users. If there's a desire to be able to monitor traffic on a wide-scale basis it tends to make sense to deploy some combination of in-line taps and on-switch port mirroring (i.e. SPAN ports).
The result of this (common) monitoring mechanism is that the output of these various taps is brought back to a common point for analysis by sniffers, performance analyzers, security devices, etc. One problem that arises with this is that I'll see the same packet as it traverses each switch. In the case of communications between two servers on two access switches I might see that packet three times - once on its source, once on an intermediate aggregation switch and then again on its destination. At the same time if I want to see traffic from one of those servers to the Internet I could see the same packet on its source, the aggregation, a core switch and then whatever connects to the Internet (four copies of the same packet).
De-duplication (and, yes, it's a real feature that several vendors implement in actual shipping products) makes sure that an otherwise identical packet is only presented once. This is really crucial because the condition of seeing the same packet multiple times can also be indicative of forwarding loops or other network problems. Similarly any kind of performance management solution is going to be gathering inflated data, security devices may see a DoS/traffic flood, etc.
Incidentally - the same issue occurs when gathering Netflow/sFlow data from multiple switches, but it's arguably somewhat trickier to implement de-dupe in that situation as there's a need to interpolate information that's not exactly in sync (vs looking at packets that should hash equivalently).
Either way the root cause is the same - taking a bunch of isolate point-in-time data and aggregating it on a device that has no way of knowing that it's receiving the same information but processed serially. I suppose one could set up three or four parallel packet captures on an as-needed basis (..and varying based on which switches in the path had the needed information) but it ends up being a lot more convenient to be able to look at the traffic from a bunch of different places at once and have it pre-processed in such a way that you can immediately look at what's interesting rather than spending hours (or likely days) determining where to look and how to pull apart the information.