What Kotlin does isn't magic. It's just more Java code that you didn't personally write, but it doesn't mean you couldn't have written something to make Java code just as succinct, albeit with a little more effort upfront.

Say, instead of using primitive Java language features, like type casting, all the time in your code, you could write specialized classes that deal with that part (Same as Kotlin does behind the scenes)

Kotlin and other high level languages abstract all that stuff away but that comes with less control and performance penalties. Which is fine most of the time.

Java does have some glaring flaws that make certain code patterns almost impossible to write well. Inheritance with the extends keyword might as well be removed completely because it's broken. Functions aren't first class objects, meaning you have to use command objects all the time to replicate that functionality. There's a divide between primitive types and Objects, and String is all kinds of messed up, but I guess that was necessary for performance reasons.

In the end immutability and NPE problems aren't actually problems of Java. A developer team can agree to treat a certain class immutable, and that's that. No need to enforce it in the language if you trust your teammates to respect the protocol (Same way most dynamic languages like Python employ a "protocol" of methods instead of a rigid interface). The NPE problem can be solved with the Null Object pattern, by replacing the null primitive with a Null object as a default value.