Прежде всего, наличие содержимого web.config в незашифрованном виде означает, что любой, кто может получить доступ к пакету услуг, может получить доступ к содержимому web.config - и это может быть больше людей, чем вы хотите. Например, если у вас есть автоматическая сборка, кто-либо из вашей компании, которая увидит результаты сборки, увидит эти данные. Вы решаете, приемлемо ли это.
Далее, не забудьте, что в программном обеспечении есть уязвимости. Возможно, в какой-то момент в IIS обнаружена уязвимость, которая позволяет легко загрузить web.config.
Далее, если у вас когда-либо случилось, что customErrors отключен, и у вас что-то неправильно сконфигурировано в web.config, может случиться так, что тот, кто выполняет HTTP-запрос к вашей веб-роли, увидит сообщение об ошибке от IIS, в котором говорится, что это и есть неправильно сконфигурирован в web.config и отображает часть web.config, где произошла неправильная конфигурация. Это может случиться, чтобы разоблачить ваш секрет - here's an example of similar exposure. Не очень вероятно, но технически возможно.
Наконец, при всем уважении ко всем облачным провайдерам вы фактически не контролируете, как данные обрабатываются в датацентрах. Они могут выбросить недостроенный диск, или какой-либо сотрудник может быть поврежден, и ваш пакет услуг может протечь. Не очень вероятно, но технически возможно. Если вы задаете такие вопросы, как этот (и это очень хороший вопрос), вы также должны учитывать этот риск.
Как обычно, нет абсолютной безопасности. Все, что вы можете, просто поднять планку. Сохранение строки подключения в зашифрованной форме, безусловно, повышает планку.
Вас также могут заинтересовать ответы на вопросы this related question.