Our "features" take anything from 1 day to 3 weeks of effort, and generally need to roll out as a whole. They are often really upgrades of existing features, and the work to continuously merge w/ feature flags, supporting both flows/designs, is just not something we've felt was worth the extra time.
We release on a 2 week cycle, the same day each time. We merge our features into the develop branch as they are ready and safe for production.
Our scheduled release day is Wednesday. The Thursday beforehand, we branch from develop into a release/x.y.0. This builds release candidates. We have a sanity check on Friday, then our remote QA team runs through them over the weekend. Any issues they find, we try to have squared away by Monday, Tuesday at the latest.
Meanwhile other team members are still merging new things into develop. It's useful to have that release branch because it lets the rest of the team keep moving - we maybe only put out 1 or 2 developer's features each cycle, the rest are still trickling in.
Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it.
For our team scale, we have a lot of users (100k's DAU), and we find this method is a nice balance between the pace of output you might get from true CI but with the reliability of a more traditional cycle.
Backend and web projects, however... Straight CI, into master, and we roll out test > staging > production when we're happy.