Taken in isolation they're exactly the same kind of interoperability issue; the difference is that Scala has the language facilities (typeclasses and implicit conversions) to solve that kind of interoperability problem and Kotlin does not. In Scala it's straightforward to write methods that work with both Java and Scala collections (either at a syntactic level by using implicit conversions or in a "true" way by using typeclasses); in Kotlin it's simply impossible to write a method that will work with both options and nullables.
Having to work with Optionals in Kotlin means just using their Java API. Having to work with Scala collections means having to convert them back and forth every time you interop with Java. The performance implications of the latter are much higher.
Almost all JVM projects are much more tightly constrained on development time than on compute time - and those where compute time is the limiting factor are unlikely to consider either Kotlin or Scala.
But in the vanishingly rare case where you have a performance-critical codepath that needs to zigzag back and forth between Java and Scala... it's still not a problem, because it's easy to work with the Java collections in Scala. The absolute worst case is "just using their Java API" (the same thing you dismiss about using Optionals in Kotlin). But since Scala has typeclasses we can actually do much better than that.
The ironic thing us that Scala could have just implemented java.lang.Iterable and/or java.util.Iterator, instead of rolling their own interfaces with largely the same methods with identical signatures.
