I am always posting provoking post on my Linkedin, and I have decided to replicate those here.Let's socialize!

Short answer:
Forget about reactive programming 😬 . In the past, it was rarely a good idea, and today, with virtual threads, it's even less recommended.
This statement from the Quarkus blogpost encapsulates my point very well:

But what are virtual threads? They reuse the idea of the reactive paradigm while enabling an imperative development model. This way, you get the benefits of both reactive and imperative models without their drawbacks!

The long answer:
Reactive architecture was developed as an alternative to the high overhead of working with system threads, as Java threads utilise them. However, due to the nature of reactive architecture — one thread per core/event loop — this approach is not really recommended. As you can imagine, it's challenging to ensure there will be no blocking processes in the request. A common example of a blocking process is relational database calls (for which Quarkus offers an extension to mitigate this issue). There are other issues associated with reactive architecture, but I'll leave those for you to research.
Before virtual threads, I would have recommended reactive architecture only in very few cases (e.g., for a proxy, gateway) because once you hit certain multi thread performance limits, you could simply spawn multiple instances of the application and use a load balancer. After all, hardware is relatively cheap these days.

Now, we have virtual threads. Finally! (It has been hard to defend Java among my Golang friends) 😄
Unfortunately, there's no such thing as a free lunch, and virtual threads do have some small challenges. These challenges are described in theQuarkus post, which I won't repeat here. However, I do want to emphasise that our Platform team needs to be aware of these challenges to ensure we have a virtual thread-friendly implementations, especially around database transactions. Quarkus, Narayana and Hibernate have been patched to avoid the pinning.
Another point to note is that the platform team should ensure we have tests against thread pinning by leveraging the@ShouldNotPin annotation fromjunit5-virtual-threads.