Given the 'encryption is only used by terrorists' climate, spending the time and money to make it work for https sounds like a hard sell.

No sources, but I have done some work in UK public sector and that kind of story would match.

As they go through compatibility testing, someone finds a problem. Maybe that's a bunch of legacy HTML which triggers mixed-content warnings, maybe that's a problem with some creaky old legacy application which expects HTTP and doesn't follow redirects or chokes on modern cipher suites, etc.

Since they can no longer say that switching won't break anything, someone pauses the project until they can fix the problems. Maybe someone suggests using a rewriting proxy to fix it but the people who own the server it'd need to run on are worried about performance/security. Maybe the legacy app is something licensed from a vendor who wants $$$ for a major upgrade rather than just making this one change. Maybe that requires a change in next year's budget because they've already allocated all of the money they're legally allowed to spend on that class of work.

It could be as simple as budget: they're using Akamai and it's likely that the contract they originally signed didn't include HTTPS, and at least in the past adding it was a non-trivial price increase. I could easily believe that this could be as simple as either a test pending a new contract or that a section of the website (or a subdomain) uses HTTPS but they added a general redirect to avoid paying the higher HTTPS rates for traffic which doesn't require it.

Tracking detailed referrer information from social media, etc. I don't agree with this goal, but it is something that's very important to people running sites with significant social traffic.

Mind you, I don't know if that's the case here; it certainly doesn't seem like caching should be a large priority for this sort of content.