Here you can find some data on the duplicate operators (including cost) in IPC 
benchmarks:
http://ie.technion.ac.il/~mkatz/results/110315/sym-count-generators-
opt.html#sym_redundant_operators

The summary of results:
Domain, #of redundant operators
parcprinter-08-strips (30),3050
parcprinter-opt11-strips (20),1451
pathways-noneg (30),1744
psr-small (50), 10869
rovers (40),69033
trucks-strips (30),369880
woodworking-opt08-strips (30),426
woodworking-opt11-strips (20),276
Sum (1396),456729

I think these ultimately come from PDDL preconditions that we take apart and
split into two actions, e.g. of the form "(or X Y)" where X and Y later turn out
to be evaluatable to constant true in certain instantiations of the operator
parameters.

It would be useful to filter these, but I think there will be a non-trivial
overhead, and there will likely remain missed optimization opportunities where
we have actions that are not duplicates, but dominate each other. I think it
would be great to look into this. As a first step, pure duplicates can probably
be detected most easily by using a dict that maps all parts of the action that
we care about for detecting duplicates (preconditions and effects, but not the
cost -- we want to detect if we have actions that are identical except for the
cost) to the action.

If we go through with this, we should update the parts of our documentation that
refer to pruning performed in preprocessing, since I suggest we drop duplicates
also if actions have different names, which is a form of pruning. Maybe we
should also make it possible to switch this of because people might want to
disable this for purposes such as generating multiple or all optimal plans.

On miconic-fulladl, the translator creates several duplicates of the stop
actions. We should avoid this behaviour or filter afterwards (at least optionally).

Example:
On task f2-2.pddl the output contains four copies of
begin_operator
stop f3
1
2 3
1
1 4 1 0 -1 0
1
end_operator