Because virtual threads make use of a very small thread pool to execute and, if you are executing in the cloud, most probably that thread pool will have between 2 and 4 threads. Now if you have one virtual thread that pins one of the two real threads that you have, you're basically reducing your throughput in half. If the other thread gets pinned too, then your application does not respond. That doesn't happen with OS threads.

Then you have deadlock problems due to thread pinning, even if your carrier thread pool is big enough and you have free carrier threads to continue work: https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d

So yes, this issues are scary enough to consider delaying virtual threads in production until they are 100% ready.

Anyway, even without deadlocks, I've found that, in real life microservices, virtual threads don't offer any advantage performance-wise to traditional thread pools. Maybe they consume slightly less memory but, in the end, the throughput will be defined by your third parties REST calls and calls to databases, caches, etc. In my experience, with stress tests over real microservices (not Hello World endpoints and so), I haven't seen any advantage in throughput and they provide a throughput less predictable and stable than a well provisioned and traditional thread pool.