Как бы вы предложили защитить это?
Хэши являются односторонними — их нельзя обратить обратно к исходным данным.
Пароли пользователей хэшируются, потому что они не должны быть обратимыми. Хэш пароля в базе данных используется только тогда, когда пользователь пытается войти в систему. Хэш предоставленного пароля сравнивается с хэшем пароля, хранящимся в записи этого пользователя.
Довольно распространённой практикой является хранение таких данных, как пароли SMTP и API-ключи, в открытом виде. Они должны передаваться в исходной форме, поэтому их хэширование сделало бы их использование невозможным. Если бы сторонний сервис принимал хэш пароля, то хэширование не давало бы никаких преимуществ в качестве меры защиты.
Как уже отметил Джей выше, если будет нарушена физическая целостность вашего сервера и файл app.yml будет скомпрометирован, у вас возникнут гораздо более серьёзные проблемы, чем необходимость сброса пароля SMTP.
Одно важное предупреждение: вы не должны использовать этот пароль SMTP где-либо ещё. Это не специфично для Discourse — это хорошая практика безопасности для всех систем и всех учётных записей.