他の皆さんが言っていることに賛成です。提案されている変更の方向性は気に入っています。また、提案されているブランチ名は古いものよりも直感的だと思います 
まだ明確でないのは、release および esr ブランチのアップグレードプロセスがどのように機能するかです（latest は簡単そうです）。常に、現在のリリース（n と呼びましょう）と以前のリリース（n-1）の両方がサポートされ、管理者である私がアップグレードのタイミングを選択できると述べています。
他のソフトウェアでの経験から、新しいリリースバージョン（n+1）が到着したときに、バージョン n+1 の利用可能性について通知を受け取ります。そして、メジャーアップグレード（Linux の apt dist-upgrade に相当）を行うか、マイナー/標準アップデート（Linux の apt upgrade に相当）を行ってバージョン n に留まるかを選択できます。これは Discourse ランチャー スクリプトに組み込まれる予定ですか？
また、リリースセレモニー/プロセスを最小限に抑えたいという要望は理解できますが、通常リリースと esr リリースの両方に、リリース前に少なくとも少し追加のテストが行われることが直感的だと思います。それは、エンタープライズ IT で長すぎたためかもしれません 
最後に、月次リリースは実際には「速すぎる」のではないかと疑問に思っています。これも主観的ですが、ボランティアとして IT 関連の管理をサイドで行ってきた自身の経験から判断すると、毎月大きなアップデートを行う時間が取れないかもしれません。そこから、Discourse の開発者としての皆さんの生活を少しでも楽にするために、四半期ごとにリリースし、個別の esr ブランチは持たず、release ブランチのみにするという可能性も考えていました。