I don't think there is much point in trying to phrase it in terms of what X has that Y doesn't, such comparisons are fraught will peril and are more indicative of a person's past decisions on what language to take. Better to talk about trade offs. Each language has a trade off that is not a big deal in terms of language capabilities. For Ocaml it is multithreading, for Scala lack of TCO+limited inference, for Haskell it's packages and for F# it's compatibility with .NET.

Those features [type classes,structural (sub)typing] you mention as being a problem simply aren't really missed due to other things on offer. While F# does not have type classes (non erasure has it's advantages to ease that lack) you don't really notice it as it turns out that kind of power is pivotal in a handful of cases and for that F# has these statically resolved type parameters which do a kind of static duck typing that is good enoughTM. The static overloading is not hit and the static methods are useful the way F# implements them (makes things simple, not as annoying or cumbersome as in C#).

Most of the time computation expressions and or simple abstract classes or interfaces with object expressions , occasionally coupled with active patterns are more than good enough for the kind of places type classes might otherwise be used. Personally, I try to make simple choices so that algebraic datatypes and records are all that is needed. I'm allergic to fancy code. I mentioned active patterns, they are really quite powerful - at the same level of power as multimethods (I have used them to solve an expression problem type thing). I believe that the use of Active Patterns and Quotations in F# is more common than in Scala due to choices in where power focus lie. I also find F#<->C# interop to be a bit easier than Scala<->Java interop for the same reason that C# -> F# objects are basically injective while Java -> Scala is only a subset.

I also think F# is more functional than Scala. Scala is supposed to be something different: a successful melding of OOP and functional. And it is the best at that I have seen. It succeeds on this better than the next biggest contender: F#. F# is more typically functional, using the usual Hindley Milner Inference and sharing a core with OCaml but with significant whitespace. So it can be very succinct. Typically functional idioms like algebraic data types, Piping, point free, currying and combinators is more natural to F# than Scala's more OOP way.

There are a number of things that Scala does naturally that are cumbersome in other languages because of how it manages to meld a powerful combination of orthogonal features. To use Scala as just another functional language is to miss its power. Those who criticize OOP have not used a language that does it right. Abstractly, in a simplified categoric setting, we can consider Abstract types (objects as an aproximation as coalgebras) and FP (algebraic data types) as duals of each other. A proper unification of the concepts gives something more flexible than either. I think Scala comes the closest. Sure you can be 100% functional in it, or replicate Java but to call it one or the other is to make the same mistake as to say that light is both a wave and a particle and think you understand what that means.