They seem to be attempting to move away from the JVM, preferring it's own multiplatform native compilation which is significantly less battle tested and, last I checked, still suffers from serious performance issues. This is a shame too because Oracle has put a lot into the development of GraalVM, which is a great solution for native compilation of JVM languages, but Kotlin still wants to tread it's own path for some reason. It creates a weird fracture in the ecosystem where some libraries only support either multiplatform or the JVM, and I'm pretty sure Java can't even be used in multiplatform projects.
Another big issue is that idiomatic Java code can often feel clumsy to use from Kotlin: for instance Kotlin function types don't map nicely to functional interfaces and the syntax for AutoClosable/try-with-resource statements is awkward. I can only see this getting worse in the future, as Java continues to develop new features and standard library APIs that are designed FOR JAVA. An example of this already happening is Java's in preview structured concurrency API. It makes heavy use of try-with-resource and offers duplicate but not necessarily compatible functionality to Kotlin's own coroutine API.
Also build times... They have gotten better but they are still much worse that any plain Java project and Java build times are already not great.