Because it's easy. CGI scripts usually retrieve the IP address in dotted quad notation from the environment. Converting it can be a waste of time if the space doesn't matter that much.

Because of IPv6.

You'll need a 128bit word for that. Plus some bignum math libraries for 32 machines that don't do 128 bits natively. (Do 64 bit machines handle 128 bits natively?)

Also watch out that you use an unsigned int. In PHP for example (and probably most other dynamic languages that don't do bignum as well) all ints are signed. So you'll have to work with the number as a string.

I'd be curious if matching 128 bit words is slower or more painful than variable-length string comparisons in any RDBMS. I would bet not.

Plus, you can't do CIDR operations on strings, making it a pain to i.e. match all addresses within a given /27.

You will often have to do a page-fault for both, so loading wont be too much an issue. However, you have to get it into an integer to compare it to begin with. So the string method is purely overhead.

A page fault, because you touched a 4 byte word, a 16 byte string, or a 16 byte binary address? We're talking about data types that fit in a single L1 cache line.

Something has to load it from disk into the cache line ..

Compatibility with other addressing formats (hostname? ipv6? $OTHER_THING?) or human readability.

Read my post again. I said store. There is no reason to store in a compiled format for humans.

You mean, besides the fact that storing binary IP addresses breaks "grep", and basically all of the rest of Unix too.

Thats fair. I was a bit narrow sighted in my vision of high-performance scenarios.