I don't know what Guido means by "values might not be comparable", but
your example is lack of transitivity.
I mean cases where == actually raises an exception. In Python 2 we did this for comparing certain 8-bit strings to unicode strings. While we've fixed that particular issue (in 3, bytes(...) == str(...) always returns False), it's still possible, and in fact even some stdlib modules do this -- I know certain comparisons of naive and tz-aware datetimes do this (which is not the same as returning NotImplemented).
However for full disclosure I should add that until just now I had misunderstood the complaint about values() -- it doesn't compare the values by identity, values views themselves are only compared by identity.
But (how's this for a nice recovery :-) that's how comparing dict.values() works, and it's reasonable given how expensive it would be to make it work otherwise (the corresponding ABCs behave the same way).
The real oddity is that an OrderedDict's keys and items views don't take order into account, even though comparing the OrderedDict objects themselves does use the order. This seems to be laziness of implementation (just inheriting most of the view implementation from dict) rather than based on some careful design consideration. Unless I missed the consideration (I wasn't involved in the design of OrderedDict at all TBH).
(And FWIW if we do fix this I might be amenable to changing the way values views are compared, but *not* by taking the keys into account. It's either by identity of the view object, or by comparing the values in order.)