Don't get me wrong, I don't mean to imply writing clean apps is impossible but I believe it's a fair assessment of the "state of the Union" for development.
Even your comment kind of alludes to the mess:
Yeah there's RxJava but it doesn't inherently solve the rotation issue because your Observables so you still need to persist the information needed to recreate them. And any long running tasks need a separate solution because tearing down the Observable will reset the operation
Googles app development team made Agera which was widely panned as an inferior NIH RxJava
Having your view's controller persist also requires custom logic because only your application will persist through configuration changes and even then the process can still get killed leaving you with nothing but data stored to disk via Parcelables or your own custom solution.
Android Devs solved asynchronous operations, the problem is keeping those operations going after a configuration change. If the operations reference the view you'll get NPE when the view is destroyed while a job finishes, and if your view references the operation you need to lay down infrastructure to let your asynchronous operations exist completely separate of the view and be able to cache their results for when the view comes back.
It's not impossible, everyone does it somehow, but it's created a lot of divergent theories on how it can be done
I also think the Activity handling of configuration changes was a mistake; it should have only ever just been the view that was recreated.
However, I don't think that in the end it's that horrible, once you overcome the learning curve.
If your process is killed and the user returns to the app, you have to be able to restore state from either the Activity's saved instance state or from some other form of persisted state anyway - whether the current approach to configuration changes was in use or not makes no difference here, it's due to the entire approach of the OS to killing and restoring processes as required (and I believe this same approach is used on iOS and for UWP Windows applications).
For handling of async results - once the owner of an async operation is not tied to a single instance of a view and is instead tied to the overall lifetime of that part of the application (e.g. retained Fragment, a Conductor controller, or pretty much any other reasonably modern view composition library), it's pretty trivial to handle. You're guaranteed that nothing else will run on the main thread for the duration of an Activity destroy/recreate cycle, so you don't need to worry about being in some unknown state. If the view was recreated due to a configuration change, rebind your view model/s when it attaches. If you're being torn down because the user left the retained Fragment/Controller/whatever the operation was tied to, you'll receive an indication of that and you can either send a cancellation signal (e.g. unsubscribe), or if that's not possible, have an isDestroyed check where you receive your result to ignore it. If you're on the back stack and still alive but have no view (i.e. view NPE), don't bind your model immediately - update your view model, and the same code you use to rebind on view reattach will kick in when the user returns and a new view is created and attached.
I should add - I do think the learning curve is much worse than it should be, in part due to this.
It would be nice if Google provided some more recommendation and best practices & patterns around this. I have come across and had to work on plenty of code that handles this all very poorly.
Even your comment kind of alludes to the mess:
Yeah there's RxJava but it doesn't inherently solve the rotation issue because your Observables so you still need to persist the information needed to recreate them. And any long running tasks need a separate solution because tearing down the Observable will reset the operation
Googles app development team made Agera which was widely panned as an inferior NIH RxJava
Having your view's controller persist also requires custom logic because only your application will persist through configuration changes and even then the process can still get killed leaving you with nothing but data stored to disk via Parcelables or your own custom solution.
Android Devs solved asynchronous operations, the problem is keeping those operations going after a configuration change. If the operations reference the view you'll get NPE when the view is destroyed while a job finishes, and if your view references the operation you need to lay down infrastructure to let your asynchronous operations exist completely separate of the view and be able to cache their results for when the view comes back.
It's not impossible, everyone does it somehow, but it's created a lot of divergent theories on how it can be done