The benefits of a six-week cycle are that keeps things moving (“stability without stagnation”). It gets new features/fixes out quickly, and sets pace and expectation.
From my experience, the downsides are that it puts a burden on app (and library) developers to keep up-to-date, and fix deprecations—particularly if they’re not immersed in the community. It also makes it harder to keep the various components synchronised, e.g. ember-cli, and documentation (incl. external blog posts and stack overflow answers), and therefore harder to learn. I think this is also compounded by weekly updates to ember-cli.
Given Ember’s similarity with Rails as an opinionated framework, and the fact that Rails is still going strong after 10 years, maybe it’s worth considering their approach?
DHH explains the Ruby on Rails release cycle in the recent Changelog podcast (at around 1:24:00), simply put: a point-release approximately every 6 months, and major release approximately every two years, and this was based on how previous releases naturally came about.
I think Rails proves that it is possible to achieve “stability without stagnation”, without having very short release cycles.