Поддерживаю сказанное другими — мне нравится направление предлагаемых изменений. И считаю, что предложенные названия веток гораздо более интуитивны, чем старые 
Пока не совсем понятно, как будет работать процесс обновления для веток release и esr (latest выглядит вполне очевидно). Вы упоминаете, что в любой момент времени будут поддерживаться как текущий выпуск (назовём его n), так и предыдущий (n-1), и что как администратор я смогу выбрать, когда выполнять обновление.
Исходя из моего опыта работы с другим ПО, когда появляется новая версия (n+1), я получаю уведомление о её доступности. Затем я могу решить: выполнить крупное обновление (аналог apt dist-upgrade в Linux) или обычное/стандартное обновление (аналог apt upgrade в Linux), оставшись на версии n. Будет ли такая возможность реализована в скрипте запуска Discourse?
Также я понимаю стремление минимизировать церемонию и процесс выпуска релизов, но моя интуиция подсказывает, что как обычные, так и ESR-выпуски должны проходить хотя бы минимальное дополнительное тестирование перед релизом. Возможно, это следствие слишком долгой работы в корпоративном IT 
Наконец, я задаюсь вопросом, не являются ли ежемесячные релизы слишком частыми. Признаю, что это тоже субъективно, но, судя по моему опыту волонтёрского управления IT-инфраструктурой, у меня может не хватать времени на крупные обновления каждый месяц. Исходя из этого, я подумал: не было бы проще облегчить жизнь разработчикам Discourse, выпустив релизы ежеквартально, убрав отдельные ветки esr и оставив только ветки release?