Stable releases matter because we try to guarantee that things will not regress from one stable release to the next. The "best" way to do this is to have good enough unit tests such that things don't regress at all, of course, but that's unfeasible.
One good indicator we should probably start the stable release process is if a significant amount of users are following the beta channel because they expect it to be "better" than the stable channel, which of course depends on which app they want to run. This is a moving target, which implies our decision to start the overhead of another stable release should have something to do with the current state of the world for real human users -- that is, in a hypothetical world where wine1.7 was exactly as different from wine1.6 as it was today, but most users are happily running apps that already work on wine1.6, we could more comfortably delay a release.
Wine1.6 was pretty good a few years ago, but if we're serious about users, we should probably start seriously talking about Wine1.8.