I think it's worth having this conversation even just to keep track of the reasoning behind the decisions.
When I looked at the codebase, at first, I was pretty impressed by the fact that we are using async calls everywhere for Java.

This is a subject pretty much full of nuances in Java land as far as I know it.

Let's try to summarize a few key points:

• CompletableFuture API is not great and doesn't play well with most of the rest of the standard library, also, using it makes the code much much harder to understand and follow (e.g. we miss an async/await construct)
• Reactive programming has become quite popular in Java, and exposing a CompletableFuture interface is going to play nicely with all the frameworks adopting this paradigm (Akka, Vert-X etc. etc.)
• Most of the libraries around are exposing still a blocking API(e.g. OkHttp), and, wrapping every call in CompletableFutures might not be the ideal solution given the number of options that comes (scheduling on which Thread Pool? Keep separated IO blocking operations from in-process computing etc. etc.)
• "Idiomatic" Java 8 code (as per Android compatibility) is not using the async API and it doesn't play nicely with imperative and blocking code
• Project Loom is coming with the promise to enable blocking idioms to easily work in contexts with concurrency and parallelism (since here we are keeping compatibility with Android I'm not sure about timelines here)