I find your comment overly dismissive of EventBus and I respectfully disagree with you on not needing to decouple components for a local app.
I've worked with GreenRobot's EventBus on a large (100M+ installs) app years ago. I worked with RxJava as well. I've also worked with more feature-rich proprietary solutions to EventBus.
EventBus is a library with a straightforward API that junior developers can use with little issues. "Launch this event and add this annotation to make sure it gets processed off the main thread". This is a very real practical advantage, that is not unique to EventBus, but it works well for large teams and does not require you to rewrite methods to return Observable objects just to be able to chain some things together. Does EventBus lead to some eventual problems? Yes. Are they manageable? Yes.
On the other hand, RxJava is a framework and, once it's in, it starts spreading Observables through all the classes in the codebase. Most developers need significant time to ramp up to become productive with it. I used to work with 30+ developers on an Android app. The app I work on now at a different company has thousands of developers working on it. People at these companies collectively concluded that RxJava doesn't bring sufficient benefits to these large teams. Both companies have ripped it out pretty quickly after the initial excitement wore off and the downsides started kicking in.
Kotlin made things much better in the recent years, but it doesn't mean that EventBus is now 'dumb' or 'toxic'. Coroutines on Android weren't widely used in these large apps a few years ago, before Google announced official support, so people were calling "new Thread()", using AsyncTask or, more likely, having ExecutorService threads created by various components in the design without any regard to CPU contention or priority of execution, and instantiating "new Runnable" all over the place.
Also, using the HTTP handler's thread to process business logic _blocks that thread_ and makes it unavailable until the logic is done running - which could take a long time. Boundaries for execution are absolutely required, unless you're working on a small app that doesn't need to care about these issues and where pretty much anything goes. You want to have control over which logic runs on which thread, otherwise you'll needlessly spend time debugging race conditions and deadlocks in production, like me. HTTP threads for delivering HTTP results, image threads for processing images, database threads for writing to the database, and you want to set priority for background, I/O and foreground threads.
That last point you have about reducing timeouts to be closer to frame rendering times is also incredibly narrowly useful. You can invest a ton of time and have the server respond in microseconds but if your users in Bangladesh are using cheap $20 Android phones over 3G connections you still have the same problem and you won't be anywhere near 32ms.