The really serious issue is how serious production users, most of whom are either not developers or offer just a few fixes see this. Besides the problems and stresses that a tight release schedule places on developers, testers, and release management, Tiki developers need to reach out to find out what their users, those who run production sites on tiki, want or need.
I would offer that while, on the one hand they want a short "improvement cycle", in order words new features and improvements "soon", they also seek longer term stability. While the LTS releases provide some of the latter, the problem is that when they have implemented an LTS release and - after some months of increased production use - would require a fix or improvement the developer community points to the release schedule, tells them that the release their using it too old, and that they need to upgrade to a newer version if they want fixes; or developers don't react at all (no time for such "ancient version" related questions or improvement needs).
I would say either 6 months, or 12 months. But not something so different from the natural cycles (once per year, twice per year). If human power is enough, twice per year, since it's the more similar to the Tiki rules we have:
"Commit early - commit often" -> "Release early, release often"