I agree it's important to reduce code review sizes, but I try to avoid reviews that end up leaving incomplete code in production such as having individual domain changes and feature flags. If a feature is cancelled before it's completed there will be unused code checked-in - which to me is technical debt.
I prefer to split domain changes into different commits on the pull request so they can be inspected individually - eg #1 Create API, #2 Consume API with model, #3 View Logic. And for feature flags, try to figure out a possible fully implemented subset of features - eg show new model properties to the user that will in the future be editable.
Feature flags are huge win for building reliable systems. You want them. Incomplete implementations should be modular, like complete implementations. Don't fool yourself, all code is tech debt. If you aren't writing modular PRs, you are in for a world of pain down the road anyway.
Also don't allow commits which break "git bisect". There are two ways to deal with this, either force all commits to be complete, or document that some patches will need to be squashed together before they are committed to the upstream repository.
This could be avoided by not merging into your master branch, and having a feature branch, from which subsequent branches are made. Then the dev can open pull requests to merge to the tertiary branch into the secondary one without affecting master.
The only healthy thing to do, is to set a deadline for each. When the deadline comes around, the code should be deleted, or a very valid reason should be brought up to extend the deadline.
I prefer to split domain changes into different commits on the pull request so they can be inspected individually - eg #1 Create API, #2 Consume API with model, #3 View Logic. And for feature flags, try to figure out a possible fully implemented subset of features - eg show new model properties to the user that will in the future be editable.