I refer to this as the “multi-paradigm curse”. The intended benefit of a multi-paradigm language is to offer a range of solution paradigms where hopefully one is the most appropriate for the problem domain. In reality the chosen solution paradigm typically is the one the programmer is most familiar and comfortable with - independent of whether or not it is actually suitable to the problem domain (which is why I take issue with using Scala as just a “better Java”).
More recently Scala has had some setbacks with LinkedIn “minimizing their dependence on Scala” (in favor of Java 8 , etc.) and Raffi Krikorian stating that in hindsight he would “use Java and not Scala as part of [the Twitter] rewrite” (OReillySACon 2015). To a certain degree language choice seems to be often driven by the cheap/ready supply of developers rather than suitability to the problem domain.
I imagine that Scala developers would feel a bit apprehensive about giving up the safety net of static typing, so they might want to know about what typespecs and Dialyzer have to offer (and what the limitations are).
Also given that their JVM-based infrastructures and libraries aren’t going anywhere, they would likely be interested in available integration options, e.g. Jinterface, using products like RabbitMQ, etc.
A receptive Scala programmer may be interested in this blog’s account of Functional Programming in Scala being used to learn Elixir.