気になったのでざっと描いてみた

省電力、省メモリとなるとこんな感じなのかなぁ。
こうなるとNoUI_FragmentにごりごりCallBacksをつける形になる。且つ、もりもりメンバー保持。

UI_Fragmentがお飾りという結果に。まさにレイアウトのためだけに生きるUI_Fragment。
でもNewは少ない。再接続だけする。ひたすら参照。
実際のところ、UIに表示されてるもの、レイアウト以外はただの投影ないしミラーだったりする。
UI_Fragmentの初期値はそのままNoUI_Fragmentから持ってきてよし。

動的な変更はUI_FragmentとNoUI_Fragmentの間でInterfaceを使う。
DialogFragmentを使うなら、UI_Fragmentでとりあえず出す。
DialogFragmentのインスタンスや必要な情報もNoUI_Fragmentに持たせておいてもいい。
DialogFragmentでの一連の処理が完了したらNoUI_FragmentにInterfaceで値を渡す。
NoUI_Fragmentは必要ならLoader起こして、自身に値を確保して、その値をUI_FragmentにPost。
UI_Fragmentで処理を行う。
全部終わったらUI_FragmentからDialogFragmentを消す。

もしもUI_Fragmentがforegroundにないなら、そこで終了。
UI_FragmentのonActivityCreatedで必要なデータは全部格納する処理が必要。
すでにあるという状況をNoUI_Fragmentが作り出している。
UI_FragmentのonActivityCreatedの最後でDialogFragmentが生きているなら消す。

アキレス腱は、NoUI_Fragmentがシステムからkillされたらoutということ。
Activityよりも長生きだけど、消されるときはやっぱり消される。
どのインスタンスもそうだけどね。
違いは、いるならシステム以外から消させない。必要であることを主張しつづけることが可能。
いらないならさっさと退場していただくことが可能。
芋づる式に消す必要があるので、NoUI_FragmentのonDestroyにUI_FragmentのRemoveを行うようにしておけばいいのかな。

メモリはActivity.isFinishing()、もしくはFragment.isRemoving()で判定して消せばよし。
Backgroundに行くだけなら消す必要はないから残す。
画像に関しては画像を丸ごとキャッシュしてメンバで保持するのか、リサイズした画像のアドレスだけ持たせて再度読み込ませるか、仕様とよく相談。
個人的には丸ごとメンバでキャッシュは歓迎したくない。
ロードは早いけど、メモリではじゃまでしかない。
10件ぐらいないならいいでしょう？と言われても他に動いてるアプリあるんで^^;;;としか言えない。

ライフサイクル管理とメモリ管理が楽。いらなくなったら消せばいいし。
投げっぱなしのスレッドや張りっぱなしのサービスよりは行儀がいいと思う。