Daniel's answer is not specific to Scala's collections library but instead
any generic type unless it's set to be invariant. That ultimately leads to a tradeoff between soundness and convenience (as mentioned in comment toward Scalaz's Monad impl).
Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations.
The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference.
Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up.
So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type".
(There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)