Есть ли перспективы у монолитных web-приложений?

Если вы про retry pattern, то звучит резонно, хотя монолит с балансировщиком могут делать тоже самое.
Если про очереди типа RabbitMQ, то монолит тоже может работать через них.
Просто возводя сетевые барьеры между кусками кода, вы не делаете его лучше.
Если вам нужен High availability, вы так же можете добавить его в монолит, это не эксклюзивная для микросервисов фича.

Подход микросервисов позволяет постепенно деградировать функциональность приложения.

Всё, что вы можете сделать с микросервисами, включая постепенную деградацию, вы можете сделать с монолитом (кроме масштабирования по частям).
Касательно вашего примера, вот примерный кусочек псевдокода

CatalogPage ShowCatalog(User user) {
  var isUserAuthorized;

  try {
    isUserAuthorized = Authorize(user);
  }
  catch {
    LogError("Authorization broken!");
    return GetGuestCatalog();
  }

   return isUserAuthorized ? GetUserCatalog(user) : GetGuestCatalog();
}

Здесь не видно, что именно делает ф-ия Authorize: вызывает микросервис или авторизирует с помощью подключенного модуля/библиотеки/пакета внутри процесса.
Но, на самом деле, какая разница? Приложение будет вести себя одинакового.

SAFe очень медленный и дорогой фреймворк, применяемый для работы с кучей унаследованных приложений, которые просто не поддерживают параллельную разработку несколькими командами, т.е. монолитов.

Если нужно что-то более мобильное и эффективное типа LeSS или Spotify, то вам нужны микросервисы. Без них реализовать вменяемое покрытие автотестами гораздо сложнее. Потом вы ловите проблему атомарных релизов (одна фича, один релиз). Даже при наличии хорошего покрытия монолита вы попадаете в ситуацию очереди релизов и скорости релиза. Нормальной частью процесса является раскатка функционала и последующий мониторинг на наличие ошибок и проблем производительности под нагрузкой, т.е. некоторый период охлаждения. Если они проявились в промышленной среде, то релиз надо откатить. Сколько этот период должен длиться? Если час, то вы можете сделать 8 релизов за рабочий день максимум. Сколько релизов делает разработчик в день? У нас 1 релиз в 3 дня. Тут мы получаем 24 разработчика в команде максимум и это крайне оптимистично. По факту охлаждение надо делать больше и предел команды меньше.

Что происходит при превышении этого предела? Начинаются релизные поезда и merge кучи фич в одну ветку релизный кандидат. Из неё фиг выкинешь фичу с ошибками. Начинается циклический хотфикс-тест-хотфикс. Тут, по нашим расчетам, мы теряем до трети пропускной способности команды.

Микросервисы это решают тем, что компоненты развертываются независимо и охлаждение у них независимое. Естественно есть куча способов снижения стоимости и рисков, но только за счёт этого окупается любая вменяемая сложность автоматизации инфраструктуры.