The regexps check for invalid IP addresses. E.g. 192.168 and 10. are reserved for intranets and will never be used on the internet. Still, they may show up in data sent by headers, or for intranet requests.
I actually have no idea about the HTTP_CLIENT_IP array key or what it represent. Another "possibly added through headers" field? Perhaps someone would care to enlighten me here.
But disregarding what I don't know... The only thing you can be certain of is REMOTE_ADDR, since this value is always present and always represents whatever computer sent the request. This, however, might just as well be a proxy as the actual user.
HTTP_X_FORWARDED_FOR may be present, but there is no guarantee. (some) proxies add to this value, which is contained in the header unless I'm mistaken, and either way this information can intentionally be changed.
What a nice proxy does, is prepend the IP address which sent the request to the proxy, before passing the request on. As such, at the first proxy, this is the user's IP, at the second proxy this contains "proxy1 IP, client IP", then "proxy2 IP, proxy1 IP, client IP". Hence the array_reverse in this case.
As for the other array_reverse calls that are found after the strok() != strok() comparison, it's to deal with IP addresses being reversed when they are not in the same block. Or some such... Once again, my networking knowledge isn't good enough. I don't know why or when the IP is reversed, just that it may be reversed.
So, is it worth doing all these things? Possibly. It all depends on your needs. One thing that might be nice is to log both (last) proxy and user ip. That way, you can decide to block a certain proxy if you get a lot of crap requests coming through it. That is, if HTTP_X_FORWARDED_FOR is set, log the last address from it as user ip, but also log REMOTE_ADDR as proxy ip. Else, just log REMOTE_ADDR as user (even though it might be a proxy).