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

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

Корпоративная сеть даёт самый частый случай. Загрузки перестают работать, потому что трафик проходит через посредника, подставляющего собственный сертификат, и проверка подлинности честно её отклоняет. Соблазн - отключить проверку целиком; цена - каждое исходящее соединение перестаёт быть защищённым от подмены, включая те, о которых вы не думали. Правильный ход - задать адрес прокси и подключить корневой сертификат организации: доверие расширяется ровно на один известный центр, а не отменяется.

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

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

Инженерный вывод простой: относитесь к переменным окружения как к части конфигурации, а не как к временным флагам. У каждой есть область видимости, срок жизни и последствия. Записанные и осознанно выданные, они делают среду воспроизводимой; розданные по привычке - создают каналы доступа, о которых через полгода никто не помнит.

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