Your examples are not semantically equivalent:
Observable<T> observable = getData()
observable.subscribe(onSuccess, onError, onCompletion)
will execute the onSuccess, onError procedures each time a new element is received.
On the other hand, with
Iterable<Future<T>> futures = getData()
futures.forEach(future => future.onSuccess(onSuccess), future.onError(onError))
the iterable delivers all the futures, and you register callbacks on each future as you get it from the iterable. But, at this point, the futures may still be running. Later, these futures may complete in any order, not necessarily in the order in which they were provided by the iterable.
Also, the first solution can received a possibly unlimited stream of data without blocking: each time a new element arrives, a callback is invoked.
The second solution can't: it only makes sense if you want to start a finite
number of asynchronous computations.
To have a better intuition, take a look at the table on this page or
this one (thanks to @Laiv for the link, I was not able to find it back).
In your first solution you have multiple values that are asynchronously pushed to your program (bottom right of the table).
In your second solution you have multiple value that are synchronously pulled by your program. In turn, each one of these values, is a computation that asynchronously pushes a single value.
An example of what you can do with the first solution is the following. Suppose that you have an observable representing all GUI events in an application:
Observable<Event> events = ...
Now if you want to listen only on the events of a given button that is,
say, identified by its label "HelpButton", you can write the observable:
Observable<Event> helpButtonEvents =
events.filter(e => "HelpButton".equals(e.getName()))
helpButtonEvents.subscribe(onHelpInvoked, ..., ...)
It should be clear that you cannot use an iterable of future here, because you do not know how many GUI events you will get and therefore you would need to have an iterator polling on events forever.