Concordando com o que outros disseram, gosto da direção das mudanças propostas. E acho que os nomes de branch propostos são muito mais intuitivos do que os antigos 
O que ainda não está muito claro para mim é como funcionará o processo de atualização para os branches release e esr (o latest parece direto). Você menciona que, em cada ponto no tempo, tanto a release atual (vamos chamá-la de n) quanto a release anterior (n-1) serão suportadas, e que, como administrador, terei a opção de quando atualizar.
Agora, com base na minha experiência com outros softwares, quando uma nova versão de release (n+1) chega, eu seria notificado sobre a disponibilidade da versão n+1. E que eu poderia então decidir fazer uma atualização maior (equivalente a, por exemplo, apt dist-upgrade no Linux) ou fazer uma atualização menor/padrão (equivalente a, por exemplo, apt upgrade no Linux) e permanecer na versão n. Isso é algo que será incorporado ao script do lançador do Discourse?
Além disso, entendo o desejo de manter a cerimônia/processo de release no mínimo, mas minha intuição seria que tanto as releases normais quanto as esr recebessem pelo menos um pouco de teste extra, antes de serem lançadas. Isso pode ser influenciado por trabalhar muito tempo em TI corporativa, no entanto 
Por último, estou me perguntando se as releases mensais são realmente “muito rápidas”. Isso é admitidamente subjetivo, mas, julgando pela minha própria experiência em gerenciar coisas de TI por conta própria como voluntário, eu posso não ter tempo para atualizações maiores a cada mês. E partindo disso, eu estava me perguntando se você poderia potencialmente também tornar suas vidas como desenvolvedores do Discourse um pouco mais fáceis, simplesmente lançando trimestralmente, e não tendo branches esr separados, mas apenas branches release.