If you think about how you use os threads today, you have two main dispatcher pools, default (cpu), and IO (for IO processing). You can now swap out the discrete IO threads with a virtual thread pool instead. You can get the "infinite" IO (blocking) task benefits of virtual threads like normal java virtual thread pools while still using the same benefits of structured concurrency that coroutines grants.

In reality, this will take a bunch of time to actually show much real results. We've been producing async future driven libraries for a long time, and they're generally pretty good at keeping the computer busy while sending out many concurrent IO requests. The real benefits are when these libraries start to support these virtual threads which should ideally lead to less complexity and some lesser compute overhead (my hopes).

For server tasks, it may simply be reducing the total number of OS threads necessary to do the same tasks, since we won't need to depend on farming out work to work pools, so it may actually make some simpler uses of coroutines unnecessary, if I can simply receive request, process, ask blocking source for info, then respond in one virtual thread, why would I need the extra complexity/cost of coroutines for this naive use case anymore?

Here's a take from Roman Elizarov (Kotlin bias) - https://www.youtube.com/watch?v=zluKcazgkV4

I imagine a lot of the missing structured concurrency will get built up over time on the Java side, but it is an interesting talk regardless.

It largely doesn't affect Kotlin's coroutines. Kotlin targets platforms where Loom is not available (e.g. Android, native.)

As a developer if you're targeting the JVM with virtual threads you may decide to use those for some workloads instead of coroutines.

In the future when targeting the JVM Kotlin maybe can use the features exposed by Project Loom to execute coroutines more efficiently, but it's not clear to me that there's much for Kotlin to gain there, maybe some small gains in performance.

They are married to Android, naturally everything that doesn't exist on Android will hardly make it into Kotlin.

And since they also want to compete with Swift and TypeScript, on their own turf, even less likely.

This is the thing with guest languages, cannot embrace the platform, always full of compromises.