You can have both. Some bigger features can take a while to complete and you can keep the pain to a minimum be rebasing your feature branch on the latest mainline branch often.
Rebasing regularly is a task that requires diligence, skill and good communication. I've built solo "out-there" feature branches that I've kept alive through careful rebasing for more than a year without issue - but once you're working on a team absolutely everybody must be onboard with the strategy for it to work... as soon as people go off on a garden path doing unnecessary refactoring[1] in a big long-lived feature branch you start into the world of pain - refactors (especially code movement within a file like function reordering) lead to all sorts of unnecessary chaos. If you're going to make a long lived feature branch you absolutely need to KISS[2] - the smaller your change set the better your chances of avoiding having a bad time.
1. IMO refactoring is one of the best things you can do for your codebase but it should NEVER happen in a branch that may be blocked from merging for other reasons - keep refactors in isolated branches if there's any danger of your merge being delayed for any reason other than an issue with the refactor.
2. Keep It Simple, Stupid - i.e. avoid any complexities not absolutely necessary for the feature.
Development, like construction, is horribly ineffective at accurate projections.
So if it's "your turn" to have the (singular) long lived feature branch, you will run over your deadline and into someone else's start date. There will be someone you're blocking who starts pressuring you to finish or for the org to make an exception and allow 2 feature branches.
And six months later, what was good for the goose will be good for the gander and then you have 2 feature branches part of the official process. Which of course means you'll occasionally have 3. After that it's like Texas Highways. They just keep getting more lanes and traffic gets worse.
