Потому что все тесты будут тормозить на 3 сек, а если элемент не появится, то просто упадет.
Thread.Sleep - временное решение  применяется только для отладки

почему все тесты будут тормозить?

Thread.Sleep - данный метод останавливает работу нашего кода на n секунд.

То есть не важно есть элемент или его нет, все равно будем ждать n сек.

мы наверное все же запускаем тесты в параллели.. если запустили в 10 потоков, то один - ок - подзадержится на 3 сек. А остальные девять пройдут нормально.

все?

А, я вас не так понял.
Все равно решение не удачное.
Если элемент будет загрузится например через n+1 секунд, то тест упадет

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

Всем привет ещё раз, у кого хороший опыт с Cypress, кто может проконсультировать по некоторым вопросам, не бесплатно. Напишите плз а личку + стоимость часа консультации. Спасибо)

Ну не совсем. Как я говорил выше, вейтер дает возможность получить ответ раньше, если он придет, и не ждать время все время в отличие от слипа.

Я отвечал на ситуацию n+1

аа сори)

Так вопрос тогда в том, как определить, какое граничное значение вейта/слипа задавать. А это уже другой вопрос.

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

У меня другой вопрос возник. А сталкивался ли кто-нибудь из вас с ситуацией, когда результат выполнения шага не должен влиять на результат выполнения следующего шага? Как вы поступаете в этом случае и какой, считаете должен быть статус теста passed (в отчете все равно шаг будет отмечен как failed) или failed?
Я в такой ситуации действую через try catch finally и последним шагом делаю ассерт на флаг, привязанный к потенциально зафейленному шагу, но который не должен помешать довести тест до конца.
В результат в отчете у меня опциональный шаг помечен как failed, тест помечен как failed и собственно последний шаг по проверке флага помечен как failed.

Хотя для ui это наверно не так актуально.

Это означает N проверок в тесте в разное время. Для этих нужд изобрели delayed assert

Аа вот как оно называется. Спасибо)

Сам по себе тестовый код лучше избавить от try catch и придумать метод или найти имплементации в интернете. Делаешь софт ассерты, а потом в конце теста проверяешь объект отложенно