Thanks @Tom, that makes a lot of sense. I had the feeling that I didn't have the context needed behind the current approach. And I think, given the small team behind MonoGame, it's a very reasonable approach, specially for less used platforms, as you mentioned.
I agree that increasing the automated test coverage could definitely help. In any case, I wouldn't be extremely concern about breaking changes. The reason is that, with smaller releases, it's easier to feel more confident about the stability of the development branch, and also it's probably easier to manually test when the automated tests suite can't help, as there are far less things to test. Smaller releases are also a good "check point" in case there is something broken, as users could revert back without loosing much functionality.
I also agree with getting the community more involved. As an idea, I wonder if releasing a release candidate version could help? I'm not even sure if this is done already, as I landed here a few weeks ago. But maybe that way it would help both getting users more involved in testing (people usually jump into new oficial versions more than particular commits on the current development branch), and also being more confident with releasing more often.
Also, it's important to remind users to report bugs, instead of trying to fix them ourselves. I remember reading something about this about MonoGame somewhere..