Understanding Handling Observable in Interactions Below the Usecase Layer

I am involved in the design and development of Android applications, but based on the assumption of developing Android applications,
I have a question about the design.

We would like to hear your opinion,
When using DDD or clean architecture in Android app development, RxJava's Observable is often used for Presenter <-> UseCase.
Business logic, etc. are handled in the background and are now responsible for returning results to the UI.

Observable.create(...)
   .subscribeOn (backgroundScheduler)
   .observeOn(uiThreadScheduler)
   .subscribe(...);

So far, this pattern is common elsewhere, but
You see this pattern extending to interaction in the UserCase<->Domain,Domain<->Infra layer.
I understand that Observable is a "library that eliminates many of the troubles associated with asynchronous processing", so if you look at this description, it looks like "asynchronous messaging is recommended even below the UseCase layer".

Observable is certainly useful, but I personally believe that bringing asynchronous to business logic can complicate the code, so I try to write the lower layer of UseCase in synchronous processing.
In some cases, it is necessary to use asynchronous due to restrictions and requirements.
Without them, you can also see statements that recommend using Observable.

After considering the advantages of Observable, I came up with the following:

Personally interpreting this, isn't the treatment of Observable at the bottom of the UseCase layer intended to respond/monitor asynchronous processing, but to benefit from (2)(3)?
I came to the conclusion that ...

I would like to ask your opinion on why you are using Observable.
I would appreciate it if you could give me your opinion on asynchronous processing at the bottom of the UseCase layer as well.