301 redirect...a little scruffy, but it works.
It's not as comprehensive as HSTS. As others have noted, HSTS tells the UA to redirect requests to the secure site, rather than having the server do it.
As I understand it, there are two motives for HSTS. One is to reduce load on the server. Yes, it's trivial to have an HTTP server answer any request received over an insecure channel with a 301 (Moved Permanently) redirection to the secure site. But that does require processing on the server, for every request, until the UA stops requesting new resources.
The other is to prevent the UA from ever sending another insecure request to the site, and that's critical because the UA will send any cookies set by the server over those insecure requests. So if server-side redirection is used instead of HSTS, an attacker who can passively (eg by capturing packets) or actively (eg by DNS poisoning) intercept the request can trick a user into making a request on the insecure channel and steal that user's session cookie. (Getting a user to make a request to the insecure URL is trivial if HSTS or some equivalent, such as SSL Everywhere, is not being used; a web bug does the job.)
From the article: which seems odd to El Reg since IE manages to navigate the Web without supporting HSTS at all.
El Reg needs to understand the latter issue with redirects, and why HSTS is important. It's not a question of "navigat[ing] the Web". I can "navigate the web" with netcat and hand-written HTTP requests; that's utterly irrelevant to this issue.
A fingerprinting vulnerability is bad; a session-theft vulnerability is worse.