[th0raway]

There are many answers, often related to company size and interest in teaching. Some large bay area companies think that training people into a FP style of Scala is too expensive/hard to hire for, and end up using it as a nicer Java. Smaller companies that do not hire 100 people to work in Scala every year just bite the bullet, expect FP, and end up wrapping a large majority of Java libraries with FP abstractions, some thin, some quite big.

I prefer an intermediate solution when I can get away with it: Localize the mutable Java objects as much as possible, and just make sure that I don't leave a team/teammate that has little Scala experience all alone for a while. This often leads to styles that might be frowned upon by both camps of programming, but in my experience, dropping to imperative code when FP solutions are harder to optimize, while making sure that mutability is well contained and doesn't cross interfaces is Scala's happy place. Depending on the work to be done, each codebase can be pretty FP heavy, or be mostly imperative with an FP facade.

The real trick with Scala is really library design though: It's very easy to make a new library that has dozens of new concepts and is hard to learn and use, all while exposing things like Shapeless HLists to the outside world, while libraries that are easier to consume and don't crush compilation times through type magic are often tougher on the author, leading to more code generation and macros. Most library authors know so much Scala that they don't realize that just using their library well incurs in quite the mental cost to new developers.