His example (around minute 12) doesn't sell static over dynamic typing for me. He asserts that using static types makes a program more provably correct but then he doesn't really back this up. In my experience a type system helps avoid mistakes in API calls and (more recently) with refactoring in IDEs. I've never seen an example where a type system makes a program more correct. I suspect we need just as much unit testing in a statically typed language as with a dynamically typed one.

Scala's type system tries to improve on Java's Generics, but in my opinion it makes things worse.

With Scala we end up with a part of the language where library writers use advanced things like covariance and contravariance, and a smaller part of the language for us mere mortals (a similar situation to C++ and Ruby). I'm preferring the Lisp style where the normal developer uses the same tools as a library writer (e.g., first class functions, closures and macros). And as far as implicit conversion, I agree with Dean's assessment that it can easily be too magical. It's necessary because everything is an object along with the static typing.

On the evolving Java front, I'd like to see JVM based languages move farther away from their Java underpinnings. Having interoperation is fine, but I'd like to only use it for third party libraries.

Finally, sounds like Dean is moving away from the everything is an object thinking similar to Rich Hickey. I find this sort of alternate very interesting as I explore functional programming after doing OO most of my career.