Seconding what others have said, I like the direction of the proposed changes. And I think the proposed branch names are a lot more intuitive than the old ones 
What’s not quite clear to me yet is how the upgrade process will work for the release and esr branches (latest seems straight-forward). You mention that, at each point in time, both the current release (let’s call it n) and the previous release (n-1) will be supported, and that, as an admin, I will have a choice on when to upgrade.
Now based on my experience with other software that, when a new release version (n+1) arrives, I would be notified about the availability of version n+1. And that I could then decide to do a major upgrade (equivalent to e.g. apt dist-upgrade on Linux) or do a minor/standard update (equivalent to e.g. apt upgrade on Linux) and stay on version n. Is that something that will be worked into the Discourse launcher script?
Also, I do understand the desire to keep release ceremony/process to a minimum, but my intuition would be that both normal and esr releases receive at least a bit of extra testing, before they are released. That might be shaped by working too long in enterprise IT, though 
Lastly, I am wondering if monthly releases are actually “too fast”. Now that’s admittedly also subjective, but judging from my own experience in managing IT stuff on the side as a volunteer, I might not have time to bigger updates each month. And starting from that, I was wondering if you could potentially also keep your lives as developers of Discourse a bit easier by simply releasing quarterly, and having no separate esr branches, but only release branches.