Re: the header name:
Keep in mind this header does get sent back to clients as a response header as well. It's probably not a great practice to be using a generic-sounding header name like "Last" there and waiting to find out what it conflicts with now or in the future (although I'll note that the only thing even close in current common use is "Last-Modified"). The norm would be at least X-Something for a custom weird header, but I feel the WMF-Something prefix is pretty valid in this context as well.
We could blend up the best of all of these concerns if we don't care about human readability much and just make it something like "X-WMFLA", too. Regardless, to be honest our pages are so inefficient and huge on average that I'm not overly concerned about the size of this one header's name to begin with. There's a ton of lower-hanging fruit than that to go after for reducing response sizes...
Re: date formats:
The stringification VCL offers of the current timestamp "now" was chosen to match the format used in Expires fields of Cookie headers, which is rfc822/rfc1123 -based (with 4 digit years and fixed GMT timezone for best compat with various cookie "standards"), so we get something like "Wed, 01 Jan 2000 01:01:01 GMT". The form we're using for Last-Access is just the easiest transformation we could do on that while throwing out the redundancy and excess precision and making it compatible with cookie data-value formatting.
In defense of minimizing our processing complexity here: In general it's important that we minimize not only the runtime perf hit of our frontline VCL (as *every* single HTTP request to us runs through this code, including DDoS attacks and celebrity death traffic inrushes and such), but also the complexity of the VCL codebase (as it's both operations-critical and horribly difficult to work on), so we tend to prefer to offload any post-processing that's not strictly necessary to elsewhere down the stats pipeline.
-- Brandon