I am sorry, what ?
I am sorry, what ?
Scala isn't functional; Scala is proper (pure) OO in a way that Java never was. Scala doesn't support top-level functions (only singleton objects), which doesn't exactly prevent it from being functional, but certainly suggests that the primary paradigm is still object-orientation.
It just so happens that pure OO, when properly done, happens to embody a lot of features similar to functional programming - Smalltalk is the easiest example of this (eg. the similarities between Smalltalk message passing and Haskell's implicit currying are very clear).
The reason for this is that it's trivial to create a good object system in a purely functional language, so the FP-OO relationship isn't an either-or so much as a 'special case' (ie, OO can be seen as a 'special case' of FP). The converse isn't so true; it's hard and clumsy to build a truly functional paradigm within an OO paradigm.
What GP probably meant is that Scala isn't a good choice for those who are coming from an FP background, since they'll likely notice that Scala seems very OO by comparison (because it is). Even on the JVM, there are other languages (ie, Clojure) which embody functional paradigms more transparently. On the other hand, Scala is a decent choice for OO programmers who want to get a taste of functional programming (or who want to incorporate those paradigms into their code), because Scala allows several aspects of the FP paradigm to come through as well.
If you ask someone coming from ML or Haskell, Scala is more "FP" than Clojure.
If you ask someone coming from Lisp, Clojure is more "FP" than Scala.
Ultimately, it doesn't matter what you call it. Pick your tools based on what they do, not on what other people call them.
This is neither here nor there. Scala has "package objects" and functions put into a package object are scoped directly at the top level of the package. They are not nested within any other object. The only downside to this that I can see, is that at the moment, a package can only have a single package object, which means all the top-level functions for the package have to reside within a single file.
That's quite a claim you're making here. I, on the other hand, pretend that object-orientedness and functionalness are orthogonal concepts.