SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature).
> while it's ostensibly interoperable with Java, there are many caveats.
> Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle.
This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are.
And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.