Secundando lo que otros han dicho, me gusta la dirección de los cambios propuestos. Y creo que los nombres de rama propuestos son mucho más intuitivos que los antiguos 
Lo que aún no me queda del todo claro es cómo funcionará el proceso de actualización para las ramas release y esr (la latest parece sencilla). Ustedes mencionan que, en cada momento, se admitirán tanto la versión actual (n) como la anterior (n-1), y que, como administrador, tendré la opción de cuándo actualizar.
Ahora, basándome en mi experiencia con otro software, cuando llega una nueva versión (n+1), se me notifica de la disponibilidad de la versión n+1. Y que entonces podría decidir hacer una actualización mayor (equivalente a, por ejemplo, apt dist-upgrade en Linux) o hacer una actualización menor/estándar (equivalente a, por ejemplo, apt upgrade en Linux) y permanecer en la versión n. ¿Es algo que se incorporará al script del lanzador de Discourse?
Además, entiendo el deseo de mantener la ceremonia/proceso de lanzamiento al mínimo, pero mi intuición sería que tanto las versiones normales como las esr reciban al menos un poco de pruebas adicionales, antes de ser lanzadas. Eso podría deberse a haber trabajado demasiado tiempo en TI empresarial, sin embargo 
Por último, me pregunto si los lanzamientos mensuales son en realidad “demasiado rápidos”. Ahora, eso es admitidamente subjetivo, pero a juzgar por mi propia experiencia en la gestión de cosas de TI de forma paralela como voluntario, es posible que no tenga tiempo para actualizaciones importantes cada mes. Y partiendo de eso, me preguntaba si podrían también facilitarles un poco la vida a ustedes como desarrolladores de Discourse simplemente lanzando trimestralmente, y no tener ramas esr separadas, sino solo ramas release.