Strange implementation of Object.Equals

Basically, this would only be of any use to developers with flawed Equals implementations. From the documentation:

The following statements must be true for all implementations of the Equals(Object) method. In the list, x, y, and z represent object references that are not null.

• [...]
• x.Equals(y) returns the same value as y.Equals(x).
• [...]

So the check is redundant in every case where the method has been correctly implemented - causing a performance hit to every developer who has done the right thing.

It isn't even terribly useful to developers who haven't done the right thing, as they may still expect object.Equals(x, y) to return true when it returns false - they could debug and find that their method returns true, after all. You could say that it would be documented to check both ways round - but we've already established that the only developers this affects are ones who don't read the documentation anyway.

Basically, when you override a method or implement an interface, you should know what you're doing and obey the specified contract. If you don't do that, you will get odd behaviour, and I don't think it's reasonable to expect every caller to try to work around implementations which don't do what they're meant to.