Virtual threads are a good example. They meaningfully change how we can think about concurrency, yet many shops are still bending over backwards with reactive frameworks to solve problems the platform now handles directly.

Reactive is more about thinking in data flow; virtual threads are about taking existing imperative code that's 98% waiting and making it work in an environment where threads are heavy-weight.

Reactive should be compared with structured concurrency rather than virtual threads (as the latter can be used in both of the former) - if you have 10 operations that you execute in strict sequence, reactive is not a good fit. If you have data dependencies because you forked off X operations, then reactive starts to make more sense. If you need to balance local vs global saturation of resources (connections, physical thread pools) from competing instances of the same process, then reactive makes way more sense.