0.8 clients were wrong to accept it, because doing so caused a failure of consensus.
Unfortunately the limit that was hit (which isn't quite as simple as 'size') was implicit in BDB and how Bitcoin prior to 0.8 used BDB. So no one was aware of it.
Extensive testing during 0.8 turned up several consensus breaking issues that were created during the database switch out, and very large blocks were tested... but the particular kind of very large block required to reveal this difference in behavior was not.
0.8 and 0.7 have different databases (LevelDB and BDB respectively). The 0.7 database doesn't accept some high-volume blocks under certain conditions (not 100% sure what those conditions are, that's for the devs to fix now). As a result, the chains forked when an 0.8 node mined a block 0.7 could not handle.
Everyone followed proper behaviors, it's just a compatibility problem. So miners should resort to 0.7 until 0.8 can prevent a fork like this from happening again.
They do not need everyone to stop using 0.8, just a majority (so that the 0.7 chain becomes the strongest).
You would need to get everyone to stop using 0.7 (or much more than a majority, or as soon as another block of this kind resurfaces the clients would be useless again).
0.8 accepts blocks that 0.7 rejects, 0.8 does not reject any blocks that 0.7 accepts. So 0.7 is more compatible going forward until the problem is solved with 0.9 etc.
There's a bug in 0.7. That bug means 0.7 clients reject what is, by spec, a valid block, while 0.8 clients accept it. So they can coexist for a while, until a block comes along that causes 0.7 to reject it.
Even once that happens, if there are more 0.7 clients than 0.8 clients, they will keep mining, eventually generating a longer chain, and the 0.8 clients will start accepting that longer chain. It's only once 0.8 has more mining power behind it that you get a split; now the 0.8 clients will keep forming a longer chain, and the 0.7 clients will be left behind, as they still see that chain as invalid (due to the invalid block), so they only see the 0.7 chain.
So, while the 0.8 clients were not "wrong" in accepting the bad block, it's pretty hard to fix the problem by convincing everyone to update to 0.8; some people may just not be able to or want to update. But it is easier to fix the problem by getting just enough people to downgrade to 0.7; as long as more than 50% of the mining power is on 0.7, that block chain will be the longest and both 0.7 and 0.8 will work fine with it.
Another way to look at it is to ignore the spec, and just look at the reality of implementation. According to the reality, 0.8 introduced a non-backwards-compatible feature allowing it to accept new kinds o blocks. In terms of protocols, this is sometimes known as "embrace and extend"; support the open protocol that everyone else supports, but add extra incompatible features. While this probably wasn't intended, the effect was that 0.8 miners got an advantage on mining new blocks; they would accept block mined by 0.7 miners, thus keeping ahead of the chain, but once they managed to mine an incompatible block, they would now be a block ahead of the 0.7 miners.
Now, what does this mean in terms of transaction security? Most likely nothing, unless there were any double spends, where the same coins were spent in one way on one chain and another way on the other. If there were double spends, you could look at both block chains and find them; given how quickly this was caught, it's pretty likely you could track down where the double spends went, and it's unlikely that the double spends have changed hands more than once given how short this split is. But there are other factors that make the double spends unlikely. Most transactions will propagate throughout the network pretty quickly, to miners on both sides of the block chain split, meaning that both block chains are likely to record the same transactions. You would have to notice this split, and target transactions at each side of the split so that miners on each side would pick up separate transactions, without the person that you are sending the coins to (and who is presumably sending you something else in return) noticing, all within the span of a few hours.
Now, given that this has happened once, I would be surprised if someone doesn't write a bot that noticed this kind of split and do just that, to see if they can get any double transactions accepted. To defend against this, anyone who cares that much (such as any large Bitcoin merchants or payment processors) can do the converse, monitoring for any chain splits and following both sides to watch for double payments, treating those as fraud and returning (or keeping) them without actually delivering the goods in question.
Good luck tracking down all the double-spends, because there were an awful lot of them: http://blockchain.info/double-spends Most of the ones I've looked at so far are Satoshi Dice bets, but there may be more substantial double-spending hiding amongst the list.
