The distain likely comes from a time period of its history where "Enterprise" patterns had been taken to an absurdist end before the community final regained it sanity. Modern java is quite expressive and ergonomic.
Those in industry in those enterprise days simply got sick of those silly FactoryFactory classes and their like.
Today there's almost no "boilerplate" as they've even made it nice even for scripting use cases and allow floating main methods, var, etc.
However, to actually compete with rust they'd need first class native support and an ARC GC replacement. Iirc they already have "pluggable" gc implementations so it's not out of the question. Java tends to be fairly conservative in features though, so may take a couple decades to get there if they even care to.
It's a little bit nicer to write but that's almost irrelevant.
It also comes with some runtime cruft.
In reality there is no Kotlin without Java, which means most projects end up a bit 'dual'; every single Kotlin project we've had (except Android) folded back onto Java. Even Scala wasn't worth it, though that's a different question.
That said I feel kotlin is almost a testbed language for java to steal features from at this point. Modern java is "good enough" now to warrant sticking with java these days. But back before some of the more recent java editions, kotlin was a boon to productivity, at least for me.
Luckily with "big" (feature and keyword wise) languages, you get to pick and choose what features you actually use. Obviously there are pros and cons, but in most cases you can control the complexity. The issue that remains is when a library or framework you use evolves to use more bells and whistles than you're comfortable with, but I'm general the kotlin community is finally large enough that there's always alternative libraries etc.
I generally just consumed the java libs directly in kotlin, sometimes with my own tiny shim layers for ergonomics. That way nothing crazy gets foisted on me w.r.t. orms etc.