The features are great for people writing libraries, but general purpose code should usually only need a subset.
In the case of Scala:
If you ever browse the standard collections library you'll run into a lot of different variance rules and implicit constraints. It is quite hard to really understand the collections library if you don't get your head around those.
If you want to use Spray for anything more complex than they spell out in their examples, then you need to understand their magnet pattern.
If you want to be able to debug a problem in Slick then you'll need to understand shapeless.
If you ever go anywhere near scalaz then you'll need to understand every esoteric symbol and operator in Scala, as well as be able to read and understand Haskell (because the patterns and types in Scalaz are often explained by reference to the Haskell equivalent)
Yes, I can set rules for my own team about what features we use internally, but I want my team to at least broadly understand the syntax and patterns used in the APIs that they interface with, which means you need to either read & understand most of the features that you aren't using internally, or avoid a very large percentage of the scala ecosystem.
Most reasonable people will agree on using a subset of the language but few will agree on what goes into that subset :)
Why is that a problem? Different people/teams will have different needs.
If I'm working on a problem where generics is a good fit and bob across the office is working on more business code where it isn't a good fit then it makes sense that we would both be using a different subset of the language.