Recently there was a good article about the State of Loom. This article explains why this approach is superior to other approaches like C#'s async/await, Rx or Kotlins coroutines. The advantage is, that the programming model is still based on threads, but that these lightweight threads are decoupled from native OS threads, so that you don’t have to worry about the cost of a thread. So the API is more or less the same as with threads as they are known today. The advantage is not only the well known programming model, but that many existing applications with usual threads can benefit from async processing. It is a non-invasive programming model, while Rx and coroutines are invasive.
In another topic about loom in this forum it was argued that coroutines could be bolted on top of Loom, but from my point of view that would only make sense for then existing (legacy) coroutine-based applications. As soon as Java has lightweight threads, there is no benefit in using coroutines.
A possible exception to my thesis could be cross-platform development, but I can not say much about it.
I don’t want to say that coroutines in Kotlin would be bad, I like and use them actually, but I think the future is loom (whenever that will be).