Это упрощённый пример. Может быть несколько фрагментов и первый Майн может допускать неавторизованного  пользователя а десяток других - нет

Ребят, как-нибудь можно вернуться на предыдущий фрагмент не пересоздавая его?

Чтобы при router.exit() или router.backTo() у фрагмента, к которому мы возвращаемся, не вызывался onCreateView ¯\_(ツ)_/¯

Судя по всему, исключение возникает в классе SupportFragmentNavigator в методе  applyCommands команда fragmentManager.executePendingTransactions(); Исходя из описания метода рекомендуется использовать commitNow. Либо можно обернуть команду в try-catch

Нет. Это советы со стека.
Команда вызывается как надо. КоммитНау совсем для другого и работать не будет

В 25.0.0 версии, такое поведение не вызывает исключений и все транзакции выполняются корректно.

самым простым решением. наверное, будет, delay в 1 милисекунду на вызов транзакции

Это всё неправильно. Достаточно предотвращать вообще такие вызовы, чем потом ловить такие классные ошибки и что-то делать, чтобы исправить это

Для того чтобы их предотвращать - нужен безопасный колбек, чтобы можно было начать выполнение кода, который может привести к новой транзакции, я пока такого колбека не нашел

Я говорю про executeCommands в CommandBuffer, такая ситуация, может возникнуть только когда первая команда ещё не выполнена, и сразу же за ней запускается вторая, ожидание в 1 миллисекунду, и попытка заново выполнить функцию, должны решить проблему

А для чего тут fragmentManager.executePendingTransactions() ? Без него все отрабатывает без крашей

Это для возможности делать сложные переходы с учётом асинхронного стека.

Разве транзакции не в одну очередь встают?

Они же по-идее выполняются в главном потоке

Если не юзать commitNow то нет

commit() можно выполняется в background потоке

Коммит не выполняет транзакцию, он ее только на выполнение отправляет

не правильно выразился, commit() ассинхронная, commitNow() синхронная

Смотрите. Один раз напишу, потом можно ссылаться на это сообщение 😉
вызов executePendingTransactions перед началом применения новых команд вызывается для того, что в этот момент могут быть выполнены не все транзакции, а нам надо выполнить бекТу какой-то экран.
чтобы быть уверенным, что такой есть и уже не участвует в транзакции.
после executePendingTransactions создается локальная копия состояния стека, и дальше любое количество команд преобразуется в транзакции без синхронных запусков (executePendingTransactions и popBackBtackImmediate) тем самым обеспечивая плавный UI. Раньше были проблемы со сменой корневого фрагмента и вообще концептуально теперь лучше (батчинг команд для сложных переходов)

посмотрите внимательно документацию (и другие проблемы есть).
я напишу все, что увидел беглым просмотром:
1) cicerone.navigatorHolder.setNavigator(navigator) в onCreate() нельзя делать - возможно у вас вообще из-за этого и ошибка (читайте док на гитхабе, там есть про onResumeFragments)
2) fragment.setRouter(cicerone.router) - после восстановления процесса роутер не просетится во фрагмент и все перестанет работать. просто сделайте поле в активити и доставайте внутри фрагмента из активити
3) навигацию во фрагменте запускайте в onResume