Role of Java in modern web development

It does indeed. You can even write code that is shared between both ClojureScript on the browser-side, and Clojure on the JVM server-side. Fulcro makes extensive use of that.

Well, answer will be long, but since you're asking...

Few assumptions: applications are living for long time, teams rather big, devs who create, maintain and extend the app often are different people. This is pretty typical for enterprise apps.

In this situation Kotlin's obsession on conciseness strikes back, because Kotlin code is much harder to read and follow than Java code. To read Kotlin code developer is ought to navigate back and forth much more often. Kotlin's conciseness is achieved by throwing out significant portion of context.

Next, 'var' and 'val' quite hard to distinguish at first look.

Next, optional chaining and elvis operator are easy to write but hard to read. This is if to ignore the fact that they're impeding the transition to functional style since they don't compose.

Next, extension methods, without strict policies and best practices tend to spread across the whole code base, blurring class API and often cause code repetition - different devs may add similar extension methods. I saw this happening even in teams consisting of just three devs, needless to say that larger teams suffer much more. As mentioned above, this can be mitigated by strict policies where and when extensions methods can be placed. Unfortunately more rules/policies/best practices results to more mental overhead and worse productivity.

Next, freedom to place any class in any file quickly results to complete mess in the code. Again, this can be mitigated by policies, which, most often are indistinguishable from rules set by Java (one class - one file with same name) except there is no help from the compiler. See note above about mental overhead.

One funny observation, which less belongs to the above but illustrates how poorly Kotlin is thought out as a language: if you have 'DSL-ised' code often, when you try to improve readability by wrapping and indenting long line you may make it non-compilable. Consequences of the optionality of the semicolon after expression.

And here you can find another similar opinion (notice that this is also enterprise experience).

About coroutines. Citing JetBrains blog:

When you write code with coroutines, however, trying to debug them can be a real pain. Coroutines jump between threads. It can be difficult to understand what a specific coroutine is doing or to check its context. And in some cases, tracking steps over breakpoints simply doesn’t work. As a result, you have to rely on logging or mental effort to debug the code with coroutines.

They're trying to address the issue, but so far coroutines are not yet usable for enterprise apps. In other words, they are about as usable as Project Loom. Frankly, I see no improvement over Java.

P.S. Kotlin has one idea (not feature) which actually is very useful - separation of nullable and non-nullable types. But this idea can be easily adopted in Java code as well (with Optional).