While I love seeing monthly (read: as soon as possible) updates featuring new features and bug fixes, I can also appreciate fewer upgrades in need to be scheduled and executed (on the admin side) and less release work on the dev side.
This is not a problem of my deployment specifically though, as I have written a script that does the upgrade for me ( ./upgrade_mattermost.sh 3.4.0 
) and a user base (about 100 users in the same timezone) that is not too picky if the chat is not available during lunch break or similar hours 
.
Personally I feel like Mattermost reached a point at which it does not urgently need new features to be released within one month. However as someone comfortable with english and already served with a full translation (german) I can't say wether this is how the majority of the user base feels.
Especially for users/deployments that are different from mine (in use case / language / user base ) I don't feel confident saying a slower release cycle is just as fine, as they might be highly anticipating an upcoming translation, a specific feature that's already scheduled or a fix for a bug impacting their workflow/interaction.
An idea basing on JeffSchering's suggestion of a split into an LTS and a regular release (which could be quite a lot of overhead I assume):
Keep the monthly release cycle for bug fixes, improvements and features that are highly requested/easily implemented (possibly through a pull request). For major new features, complex changes etc. make a bi-monthly schedule (using every other release of the monthly cycle) as you lay it out in your OP.
While this does combine some cons of both solutions, it also combines pro's. It would give room for more work on the bi-monthly release and take work off of the monthly release. At the same time it keeps frequent updates for wanting users, but might not make updating as necessary (/mandatory) for already satisfied users.