There's no magic to it; it's actually based on time slicing. The reason why your physical machine has only 10 physical threads, but you see a significant improvement in response time when your JVM threads exceed 10, is because your service load is I/O-bound—it's an I/O-intensive program. I/O does not consume CPU time slices because modern operating systems handle I/O asynchronously (this is independent of the programming language you're using; at the lower level, it's triggered by interrupts rather than the CPU waiting in a busy loop).

You could consider changing your service load to something like a for loop, for example, running for 10^9 iterations. In this case, when the number of concurrent requests exceeds your physical threads, you'll see that increasing the number of JVM threads beyond the number of physical threads doesn't help with response time. In fact, as the thread count increases, the response time may gradually increase because the number of physical threads hasn't increased, and adding virtual threads introduces the overhead of context switching.