After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult.
For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages.
(Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)
I agree, and I think Julia's designers have chosen correctly not to use the JVM (although, in the comments below you'll find that Julia uses boxed types for "structs" as well, though it would be far easier to build true array-embeddable complex types on LLVM than on the JVM). However, value types for the JVM are a work in progress (as well as tail-calls), and I think they might have already been implemented in the DaVinchi project (future JVM improvements), and so will find their way to the JVM in due time (see https://blogs.oracle.com/jrose/entry/tuples_in_the_vm). Until then, scientific computing languages will most likely choose a different platform.
http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi...
http://lambda-the-ultimate.org/node/4405