usecase層より下層でのやりとりでObservableを扱うことについて

私はAndroidアプリの設計・開発に携わっているのですが、Androidアプリ開発を前提に,
設計について疑問があります。

皆様のご意見を伺いたいのですが、
Androidアプリ開発でDDDやクリーンアーキテクチャを採用した際, Presenter <-> UseCase のやりとりにRxJavaのObservableを使うことがよくあります。
ビジネスロジックなどの処理はバックグラウンドで行い, UIへ結果を返すのにこれで担っています。

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

ここまでは他所でもよく見かけるパターンなのですが、
このパターンをUserCase <-> Domain, Domain <-> Infra層でのやりとりにまで広げているものを見かけます.
私はObservableに対して"非同期処理にまつわる面倒の多くを解消してくれるライブラリ"程度の認識でいるため、この記載を見ると"UseCase層より下層でも非同期によるメッセージングを推奨されている記載"に見えてしまいます.

Observableは確かに便利ですが, 個人的にはビジネスロジックに非同期性を持ち込むのはコードを複雑化させる原因であると考え, UseCase層より下層での処理は同期処理で書くようにしています。
制約や要件の都合上、どうしても非同期を使う必要のあるケースもありますが、
それらがなくともObservableの使用を推奨するようにとれる記載も見かけます。

Observableとすることの優位性を考えた結果、下記が思いつきました。

Androidの(貧弱な)バックグラウンドタスクAPIの代用
レイヤー間のインタフェースに柔軟性(エラー応答, 複数回応答, Pub/Sub)を持たせる意図
StreamApiの代用
Promiseの代用
処理のカプセル化/処理のペンディング(後からsubscribeで発火させるコマンドパターン)

個人的にこれを解釈したところ, UseCase層より下層でのObservableの扱いは、非同期処理の応答/監視を意図したものではなく, (2)(3)の恩恵を受けるための策ではないのか？
との結論に至ったのですが...

どのような理由があってObservableを使用されているのか, ご意見をお持ちの方にお聞きしたいです。
UseCase層より下層での非同期処理についてもあわせてご意見いただけると助かります。