It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved.

Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.

Java and JVM are developed together, Kotlin just adds syntax sugar on top.

If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?

Because there are benefits to the JVM and interoperability with Java

Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".

If Kotlin's only improvement over Java were its scope functions, that alone would be an overwhelmingly good reason to migrate. Scope functions are awesome, cannot stress that enough.

Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate.

But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.

import static

Kotlin fixes just trivial things - like nullability for example. Java still doesn't have a good solution, only about 5 bad ones and nothing is in sight. It even looks like Java designers simply don't consider it a problem anymore ...

Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).

When teams go so far as to consider alternatives to the JVM, memory footprint and poorly tuned GC are typical reasons.