(==) is about value comparison; pattern matching is about constructor comparison, which is on a higher semantic level as value equality is only meaningful within the same constructor.

"Circumvents"?  You make it sound like the point of typeclasses is to restrict things.  In fact, the point is to *undo* the restrictions necessarily introduced by polymorphism:  if you don't know the type of something, you don't know what you can do with it.  Typeclasses let us say "this can be any type, but we need to be able to do <x> with it".  They don't circumvent; they *add*.

Are you approaching this from an OO perspective, where you can throw messages at anything and hope they stick?  Haskell, ML, and similar languages are based on strong types:  if you know the type, you know *everything* about its possible values.  Dynamic message passing means you can send a message to an object that doesn't know what to do with it, producing a runtime error; the whole point of strong typing is to make using an operation not supported by a given type a *compile time* error.  That is not to say there aren't hybrid systems (see O'Caml) or static strongly-typed OO systems (see research papers about OOHaskell; this hasn't been followed up directly, although it's the basis for a number of other research topics).  But in general, the design of a Haskell or SML program is in designing types that reflect the problem space, such that (a) if you do something that isn't quite right, it is a compile-time error instead of a runtime error, and (b) the types of functions are themselves the solutions to the problems (that is, you would like the implementation for some function to be obvious from its type; when it isn't, this usually means some kind of dependent typing is going on, which Haskell can't express directly, or that you otherwise haven't actually captured the problem space with your types).