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

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

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

Ну вот я об этом и говорю - если да, то зачем тут вообще гард?

потому что гард не для исключительных ситуаций ) а для контроля доступа

т.е. заход неавторизованного пользователя в админку не является исключительной операцией. Сама гарда по умолчанию реализует правильное поведение с возвратом булева значения

К сожалению в nest достаточно коряво решены некоторые вопросы в которых провоцируется выкидывание эксепшенов как части управляющего потока (то самое goto-программирование)

Непонятен посыл: должно работать если я уберу обработчики исключений [бизнес логики]
1 А зачем их уберать?
2 В разных языках разный механизм работы с ошибками, они в том числе были придуманы и для ситуаций с бизнесовыми кейсами, утверждение "давайте использовать исключения только для таких-то ситуаций" не более чем вкусовщина. Если язык предоставляет механизм обработки исключений то для меня не понятно зачем от него отказываться

Прости, не очень хорошо понял этот момент. Почему заход неавторизованного пользователя в админку - это норм?

Хорошая дискуссия пошла )

Контроль доступа предполагает прерывание исполнения в случае отсутствия доступа, верно?

потому что она светит наружу и любой пользователь по урлу может постучаться. В этом нет исключительности ситуации, это просто часть бизнес-логики, что в эти страницыв нельзя пускать людей без авторизации

нет. он предполагает реакцию на негативное поведение. например отрисовка страницы запрета доступа

Хорошо, тогда я зайду с другой стороны - а в каком случае можно выкидывать исключение тогда?
Ведь если ты находишься в том месте кода, в котором ты вот сейчас собираешься написать ручками throw new Error(), то это уже часть бизнес логики - ты дошёл до этого. А значит вместо throw ты можешь сделать что-то другое

если ты можешь сделать что-то вместо выбрасывания исключения — сделай это! исключения это крайняя мера, например, падение бизнес-логики

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

Тогда исключение вырождается во что-то типа undefined is not a function

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

Не всегда. Но вообще чем их меньше — тем лучше. Исключения лучше оставить совсем низкоуровневым штукам. Ну вот возмём бизнес-логику — что означает порождение в ней исключения? Скорее всего 500. Так как мы не сможем его корректно обработать в другом слое, те же самые нестовые HttpException в бизнес-логике недоступны и никакого влияния через них на приложение она сделать не может.

У тебя может быть такая комбинаторика входных данных, что ты не сможешь корректно с ними работать в бизнес-логике, при этом по отдельности каждое поле пройдёт валидатор.