Sorry but I think I don't get it.
You said:
> started ettercap -G with and without this pr.
> ...
> the first one finished the second wasn't even started.

Mean the first (with this pull) finished and the second (without this pull) hasn't even startet? Other way round would make sense.

> changing to
> ec_usleep(GBL_CONF->arp_storm_delay);

Sure then we're there as we were before handling *arp_storm_delay* as micro rather than milliseconds.

> yes, the first takes 1 minutes, the second 1000 minutes.

Assuming you swaped the two cases, taking 10ms as the inter ARP packet delay would even end up in more time to elapse to scan 16777215 hosts: 0,01s * 256³ hosts makes 167772,16 seconds makes 2796,2026 minutes makes 46,6 hours in theory.
If we take the interpacket delay of 10 ms for granted, it takes that long.

We could think of decreasing it to 5 or 1 ms. Another idea could be to automatically decrease the delay if hosts count over a certain number.
Suggestions? Also @eascob? 
However, scanning a /8 network shouldn't happen in reality that often. Something between a /16 and a /24 is more common.