In this case, it seems that some of the services were using https to protect the cookie and had secondary exploits, and others weren't protecting the cookie and so the secondary exploits weren't needed.
(Also, your suggested fix doesn't work; what's causing the server to send the hidden form field? There's no obvious way to send it to the user-who-has-a-cookie unless you also send it to the attacker-who-has-a-cookie. Unless you make the user log in on every page view, which would be ridiculous (although at least Bugzilla can optionally fall back to that mechanism if the user isn't accepting cookies).
This isn't exactly a new exploit (I remember the Firesheep event where someone made hijacking Facebook accounts like this user-friendly, but don't have a link handy). One problem with actually doing this is that you need access to the data as the victim's sending it (e.g. via sniffing unencrypted wi-fi, or physical access to the network that the victim is using); that still gives several possible targets (especially the wi-fi angle), but makes it much harder to use against arbitrary targets.
(The simplest fix, of course, is to use https for all cookie handling, which probably means https for every page access.)
So this is old news, although a reminder that this is still possible is definitely worthwhile.