I know this is an old question but I'm answering it now as I also wondered about this and did some digging.
As of the time of this posting, http://static.ak.facebook.com/connect/xd_arbiter.php is being delivered by a server that supports gzip and will respond correctly to [HTTP requests for a gzip enconded page][1]. It also sets a [long cache expiry][1] and is being served by a Content Delivery Network (Akamai) on its proprietary web server software on a Linux operating system. The source code of the page is minified.
It's possible your browser had gzip/deflate compression turned off when you ran the test. Most modern browsers should be retrieving the compressed page. Interestingly, in my own testing, I found that the overhead for gzip compression on this page led to an overall slower response time [by nearly 500ms][2]. I tested several times with similar results though I did not exhaust the browser/platform/geolocation variations to come to any conclusive determination. YMMV. While Page Speed correctly points out that compression would reduce the transfer size (currently from 23.9KB to 9.0KB), it's not at all obvious that compression would necessarily improve performance. Nevertheless Facebook's Akamai servers support gzip encoding and most modern browsers request gzip by default.
[1]: Response header:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Content-Encoding: gzip
X-FB-Debug: ZUlg004d1ohc18J/hpYpvJFY86ckxMlwwhVTb5y01B4=
Vary: Accept-Encoding
Content-Length: 8796
Cache-Control: public, max-age=31372439
Expires: Sun, 12 Apr 2015 04:19:30 GMT
Date: Mon, 14 Apr 2014 01:45:31 GMT
Connection: keep-alive
[2]: Sample result with gzip compression and without.
