Btw, you get a very similar vulnerability through
timejacking (aka "forcing clock drift"). It's in the highest class of vulnerability according to the
Bitcoin weaknesses page. It does almost exactly what you propose, by forcing the node's clock to be more then 2 hours out of sync, it will reject a perfectly valid block while the rest of the network continues normally. Since the rest of the network is building off that block, the victim node will not see any new blocks except for "poisoned blocks" sent by the attacker (who needs a bit of computing power to produce them, but nowhere near 50%).
I agree, nodes should "respect" block headers with the correct proof-of-work regardless of who sent them. Although, this wouldn't benefit a victim of timejacking, I can't think of why it would be bad to accept them.
As for your last point, how does a node actually determine network speed? Is it averaged over a certain number of previous block timestamps? If it can measure this reliably and without too much latency, then this could be a very reliable indicator of something abnormal occurring. In addition to targeted attacks like you suggest, if someone tried to DoS the main mining pools in an effort to boost their own computing power past 50%, there would be a similar drop in global computation speed and the client would go into some sort of safe-mode.