There's a lot here to unpack, so sorry for the length.
Your question title is painting a false dichotomy. The two are not competing ideas, actually quite the opposite, to the point that reactive Kafka is a thing.
However, it's also true that the reactive programming community has created some excellent projects, such as Project Reactor or RxJava that kind of turn HTTP communications into a pseudo-message-driven solution.
The reactive libraries in Java are certainly a nice fit for mesage driven solutions, but they can near enough be used for anything (and arguably are often used for cases where they wouldn't always be the best fit!)
Can RSocket/Reactive microservices be actually considered event-driven solutions?
Rsocket and reactive microservices are two different things; while they play nicely together and are often used together, they're not one and the same. RSocket is a lot newer for starters, so most reactive microservices out there already probably aren't using it.
Reactive microsservices, or microservices written in a reactive fashion, mainly relates to the way that they're written internally. Being reactive, the backend is non-blocking, so they're arguably more efficient - especially in cases where a stream of data needs to be sent out on a long-term connection. Non-reactive services would have to hold an individual thread open for this entire time to manage that connection, whereas a reactive service can simply be idle unless a message is actively being sent out.
Reactive microservices are certainly event-driven internally. However, that says nothing about the means which a reactive microservice may use to communicate. It could use RSocket, plain HTTP, MQTT - you can make no guarantees about what it's using just based on this protocol.
RSocket however is a protocol that's designed to play particularly nicely with reactive services, work over multiple transports, and (as a binary protocol) is more efficient. This leads to your next point:
Aren't they just a way of improving the performance of the traditional request-response systems?
RSocket certainly can be. You can use it as a traditional request/response system and just obtain improved performance, with everything else staying "classic". However, it also supports streams of data (single and bidirectional) as well as fire and forget semantics and resumable streams at the protocol level, so has feature advantages as well as performance advantages.
This may be where some of the confusion stems from, as (without RSocket) one might choose to use middleware purely because it makes it easier to manage those streams (rather than to decouple anything specifically.) In this case then yes, the middleware wouldn't be required.
Working on top of the transport layer, RSocket also doesn't care where it's used, or what's sent over it - so it's just as happy operating in a server to server environment over TCP as it is in a bidirectional server to client environment over websocket.
aren't those Rsocket+Reactor microservices still coupled exactly as HTTP based ones used to be?
Yes, they are still coupled - that's not the problem Rsocket tries to solve. It's a protocol, it's not middleware. Kafka could, for instance, support Rsocket natively later. (I can see no indication it will at the moment, but there's nothing that would technically stop that.)
In which scenarios is each of them more recommended?
If the only reason you're using middleware is to easily generate and manage a stream of data (rather than being constrained by request / repsonse), then Rsocket coupled with reactive libraries now arguably fulfills those criteria on the protocol layer.
However, if you're using middleware for decoupling purposes, then you'll almost certainly want to carry on using that. The continued use of said middleware, however, certainly doesn't preclude you from using reactive libraries and/or Rsocket in your implementation.
