I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route.

As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.

I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are:

Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior

Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically

Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions"

Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways

Makes sense, that's a solid approach. No nesting or any other nonsense. But clearly it takes quite some bootstrapping in order to make this functionality solid (as it should be out of the box)...

Fragments follow the general story of Android Framework: tried to be too flexible, introduced unneeded complexity for everyone, suddenly flexibility is of questionable usefulness