First of all, your solution doesn't always work in .NET.  The description of the CompareTo method says it returns an int that is less than zero if x < y, zero if x == y, and greater than zero if x > y.  Unless you know for certain that the implementation of the CompareTo method you are calling returns -1, 0, or 1, you shouldn't make that assumption (and for maintainability, it's probably not a good idea to do this anyway).
I admit that this problem is not insurmountable.  For example, you could define the CompareTo method to, instead of returning an int, return an enum with the possible values LESS_THAN, EQUAL_TO, GREATER_THAN, or something of the like.  You could even capture floating point comparison semantics fairly easily, and given a few other language features, make this fit nicely into an OO style.  For example, you could have an interface PartialOrdered that defines a CompareTo method, and an interface Ordered that extends PartialOrdered.  Floating point classes would implement PartialOrdered and integer classes would define Ordered, for example.  If the language has built-in design by contract, you could specify that Ordered's CompareTo never returns UNORDERED.  There is perhaps an even better solution, which requires a "restricted" style of inheritance (as "restrict" in XML Schema, but also somewhat similar to bounded types in Ada), and convariant return types: PartialOrdered's CompareTo returns the enum PartialOrdering and Ordered returns the enum Ordering, where Ordering restricts PartialOrdering.  Throw generics and or implicit casts into the mix and you have a solution that covers comparing floating point with integers.  This is to me an elegant and attractive solution, and the features that it relies upon are all reasonable things to put into a modern language.
However, to answer your question, no, it is not necessary, but it seems to me to be desirable.  First, in pseudocode, you often see things like:
case 1: x < y
case 2: x > y
...
Not that real code should always be written like pseudocode, but in many cases I think it is a good heuristic for readability.  Second, since this is a very common type of control structure (in whatever form it takes), I don't see any reason why it can't have it's own syntax.  Third, although the two solutions are semantically equivalent, there is a trade-off involved.  Although the standard switch statement solution has the advantage of not adding anything new to the syntax of the language, and thus makes that part of the compiler simpler, it creates more work for the optimizer if you wish to output the same code.  That is of course, unless the intermediate code generation treats a switch on a comparison result for primitive types differently than other switches, but if this is case, why not reflect this in the original language?  I can't make any solid claims about which would compile faster in the general case (my experience writing compilers is very limited), but it seems reasonable to design a language such that the front end does as much of the work as possible.