This code is a security control, and as such, it must be evaluated against the threat it was intended to control. In this case, there is no special access being granted based on IP address. Instead, IP address is being used as an additional constraint on an already strong authorization mechanism (HTTP Cookies).
It is true that an attacker could spoof a user's IP through the X-Forwarded-For header and bypass this additional check, but that means that the attacker must not only know the user's session ID (cookie), but also the user's IP address. This makes exploitation of session-stealing XSS more difficult.
Consider the other ways this control could have been approached. First, if the control were not in place at all, then any session-stealing attack (XSS, traffic sniffing, SSL MITM, etc) would result in a fully-usable session for the attacker, with no extra work.
Instead, if the control were implemented without consulting the X-Forwarded-For header, but only HTTP_REMOTE_ADDR, then an attacker who is behind the same proxy (in a school or business, for instance) would not need any knowledge of the control or the user's internal IP to have a fully-usable session, since all outgoing HTTP sessions would appear to come from the same IP (that of the proxy).
By adding the check for X-Forwarded-For, the control requires an attacker to have knowledge of the user's IP address, and the ability to spoof it in the X-Forwarded-For header (not every attacker is completely unconstrained, so there is a reduction in risk. Not an elimination of risk, since we must assume there are some unconstrained attackers.)
One way to possibly strengthen this control would be to keep an extra bit of information: The source of the last IP address that was used. For instance, if the session were first granted and associated with an IP that came from HTTP_REMOTE_ADDR, the control could require that future traffic on that session must come from an IP gleaned from HTTP_REMOTE_ADDR, not X-Forwarded-For. This eliminates some chance for spoofing. The gains for implementing the check in reverse (preferring X-Forwarded-For over HTTP_REMOTE_ADDR) are probably not worth the effort, since it is much harder to spoof a real network address than an HTTP header.