I think it was that 0.0.0.0 is an invalid destination address so smart programs might not even try to connect, whereas 127.0.0.1 is valid so you'd have to wait for any program to try to connect and fail.
As defined in RFC3330 ....
0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network [RFC1700, page 4].
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].
Thus. An IP from the 127.0.0.0/8 range shall be the correct destination when you wish to null route traffic (although on certain *nix/*nux boxes you can do some fancy tricks routing to /dev/null ... ).
However, every program I've tried today still tries to connect to 127.0.0.1 if you give it 0.0.0.0.
From the machine at which I am presently sitting.
Code:
$ ping 0.0.0.0 PING 0.0.0.0 (0.0.0.0): 56 data bytes 64 bytes from 172.16.123.1: icmp_seq=0 ttl=64 time=0.424 ms 64 bytes from 172.16.123.1: icmp_seq=1 ttl=64 time=0.266 ms
^C
$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.062 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.033 ms
^C
As you can see from the responding IP and the RTT time, it's not the same thing, and just to prove it.....
$ ifconfig en0 | grep 172.16
inet 172.16.123.194 netmask 0xffffff00 broadcast 172.16.123.255
$ route -n get 0.0.0.0
route to: default
destination: default
mask: default
gateway: 172.16.123.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
$ route -n get 127.0.0.1
route to: 127.0.0.1
destination: 127.0.0.1
interface: lo0
flags: <UP,HOST,DONE,LOCAL>