Yes. I heard you make the same argument last night. The answer is not cut and dried. Should we "fuck" the users a little bit now (by making them upgrade immediately) or should we patch clean efficient code (0.8 ) to protect buggy slow code (0.7), thus risking a more serious "fucking" in the future?
Do not misunderstand. In the heat of the moment I might well have made the same decision as you. But decisions have consequences: (1) Bad code was protected and (2) influence born of community respect was spent. By being aware of those consequences, you might be better prepared to guard against their potential repercussions.
You are intentionally ignoring the real consequence. It isn't that users are "forced to upgrade". Devs have recommended security upgrades in the past. It is that users who didn't upgrade (possibly because they are unaware) would have been easily "robbed". Downgrading v0.8 has no lasting security implications. Allowing the network to remain forked presented a real threat to the security of user's transactions. It would be asinine to chose anything over the security of the network. The news of this fork has been relatively muted. Can you imagine if the decision to force through v0.8 had been made and thousands of users were robbed for millions of dollars worth of Bitcoins in 51% attack, accepting bogus generated coins, and even trivial no-hash power double spends.
Which presents a real THREAT to the trust in the network. The need to upgrade or lack thereof is a strawman. My guess is you will now make another strawman attack about needing to upgrade as you have done twice now. Don't worry I won't see it so you an "winz the internets".
Hmm .. the bug (or do you call it a hidden feature?) effectively touched bitcoin-miners and not directly(!) bitcoin-users. So the other obvious solution, which Pieter also suggested at first, was to push the longer chain, the one which grew faster and not to conceal/press effectively bitminers to do an effectively 51%-attack for the "good" of the network on this chain, because the 0.7-fork is "correct". This dubious politic is highly questionable, IMHO. On the other hand, effectively convincing/forcing miners to switch to 0.8 would surely have had the advantage of a much more equal code base for almost all miners afterwards.
Appendum: Again a very important issue, which reflects a real-time behaviour is: how can one estimate which approach (if we restrict us two only these 2 alternatives) will succeed significant earlier?
smtp