I suggest this gets some attention especially if the collected remote IP address is used to permanently ban, restrict access, or redirect a browser based on an offending IP address. Which is how this is custom implemented on many distributed web application packages and the way some users implement it.

Issues:
1/ On 'cluster' type server configurations, REMOTE_ADDR can often be (as is the case with rackspace when https is on) the upline load balancing proxy rather than the remote clients ip. So one could get into strife by for example, restricting access which could result in a complete DoS of the site to all users because the upline proxy IP was mistakenly restricted/redirected.
2/ Again on cluster type and some cloud configurations, like Cloudfare for example, they have their own header HTTP_CF_CONNECTING_IP which is the remote IP, and REMOTE_ADDR is again an upline proxy.
3/ HTTP_X_FORWARDED_FOR can often be a string of ip addresses rather than a single IP where sometimes the first IP is the remote client and in other configurations its the reversal of this.
4/ HTTP_X_FORWARDED_FOR like many other IP headers can be spoofed therefore there needs to be a boolean IP address check function as well before committing any content from that header into a database.

5/ if IP restriction also includes restricting access to IPs collected from HTTP_X_FORWARDED_FOR, it could be then possible in some server configurations for an attacker to include any IP they wish in the HTTP_X_FORWARDED_FOR using a banned request query string to trigger the restriction.