I'd stress the fact that 90% of network interacting Java code is blocking and is therefore not suitable for use with Scala's concurrency model. Worse, it will work fine in testing and small workloads, but quickly you run out of threads in your execution context and find yourself with a broken production system.
Erlang differs for two main reasons. First, BEAM has a scheduler that will prevent blocked processes from tying up OS threads. So even if a library only supports synchronous calls, it will still work without interfering with other parts of your application. Second, everything is culturally designed around OTP (the standard library for concurrent applications). Libraries tend to support async modes in ways that jive well with the rest of your codebase. There aren't really competing standards like Akka vs Finagle in Scala. Again, even if the code does not support async it will still work. Async is just an optimization (not just for performance, but the wide swath of runtime inspection tools work better on async designs).
Erlang differs for two main reasons. First, BEAM has a scheduler that will prevent blocked processes from tying up OS threads. So even if a library only supports synchronous calls, it will still work without interfering with other parts of your application. Second, everything is culturally designed around OTP (the standard library for concurrent applications). Libraries tend to support async modes in ways that jive well with the rest of your codebase. There aren't really competing standards like Akka vs Finagle in Scala. Again, even if the code does not support async it will still work. Async is just an optimization (not just for performance, but the wide swath of runtime inspection tools work better on async designs).