Java's virtual threads make it possible to write blocking-style code that scales to a huge number of concurrent connections, without the platform-thread overhead that used to force teams into reactive programming models just to handle high concurrency.
That's a genuine win for I/O-bound workloads — services spending most of their time waiting on a database, a downstream API, or a file system. It's a much smaller win for CPU-bound workloads, where the bottleneck was never thread count in the first place.
The practical takeaway: virtual threads are worth adopting for most typical web service workloads, but they're not a substitute for actually profiling where time is going in a slow service.