One reason why is for the case where you are presented with an address text like "180.076.006.001", or an invalid address like "180.176.6.300".

$ENV{'REMOTE_ADDR'} looks like CGI or a CGI emulation like FastCGI. In both cases, the source of this data is the web server, converting binary data from socket functions to a readable string. No webserver I know delivers IPv4 addresses with leading zeros in $ENV{'REMOTE_ADDR'}. Perhaps some embedded one does, to save some bytes in sprintf, but then it would be rather unlikely that you can use Perl there, on a machine where every byte has to be used carefully.

Invalid addresses in $ENV{'REMOTE_ADDR'} can have only three sources:

An intentionally malicious webserver

Why are you running your code there?

A hacked webserver

Someone can control the webserver, or at least invoke your CGI with malicious data. Looks like the webserver was not properly administrated. So why are you running your code there?

A bug in the webserver.

The CGI routines in the major webservers should be stable, so it is very unlikely that you find such a bug there. So, your code must run under control of some pre-alpha-quality webserver. So once again, why are you running your code there?

Of course, it does not hurt to validate all input, including the CGI environment variables. Validating $ENV{'REMOTE_ADDR'} as an IPv4 address has the nice side effect of not accepting IPv6 addresses. So the CGI program, written to support only IPv4 addresses, will fail early and securely instead of misreading an IPv6 address as an IPv4 address when called from an IPv6 client.

Alexander