Usually often is better than a massive one.
Smaller, more frequent, pull requests are almost always better.
I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.
There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.
There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.
Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.
Also note that sometimes I need to cherry pick commits into a separate branches. If what needs to be cherry picked can be put into a single commit it makes it easier to move it around to other branches. This is a case where actually having few commits is better, but its not exactly the standard process if your cherry picking around.