давай ты

нет уж, давай ты

Я увидел, все ок

нас двое против одного

где, покажи

)

там нету

чет лень

давай ты

ой всё

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

В случае с гардом не все так однозначно. Если на выходе мы хотим иметь пустить или не пустить на страницу, можно объединить 4в1, но тестировать станет сложнее. А также переиспользовать. Скорее всего, это будет гард, существующий для одного конкретного кейса.
Но иногда логика бывает сложнее, чем просто не пустить на страницу- нужно дать понять человеку, что произошло в зависимости от разных условий, и вот тут-то удобнее разнести логику по разным гардам.
К тому же, гард, выполняющий одну проверку, может переиспользоваться с бо́льшей вероятностью в проекте, чем мега-сложный-гард с сложной логикой.

А причём тут переиспользование?

Тут вопрос как раз в том, что если есть взаимосвязь, то она должна быть в одном месте определена.

Мы создаем разные сервисы и разные компоненты (или разные гарды), каждый из которых делает свою задачу.

Переформулирую)

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

Почему бы и не указать)
Как бы ты это сделал?
Кстати, я тоже считал, что гарды отрабатывают по очереди
canLoad:[Guard1, Guard2]

Я бы сделал их реактивными и независимыми

Но тут вопрос в другом, что они зависят друг от друга, и был упомянут responsibility principle

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