It doesn't have to be an either/or. The method that I recommend to my reports is to develop the feature in a large WIP PR branch, get some rough reviews on the macro architectural choices in that PR, and then once you have a greenlight on the larger approach, break it out into smaller PR's that each represent a smaller change necessary to effect the feature.

There are definite benefits to shipping less code to production in one atomic deploy. When something breaks (and it will), you want to wade through as little code as possible while things are burning in order to identify what went wrong. Sure, you could just revert everything that went out with the last deploy, but sometimes things aren't that straightforward. Say when there are other sibling changes that are not easily roll-backable that you'd have to clobber to do a pure rollback. In these scenarios, it may be safer (albeit slower) to revert your individual change and deploy the revert by itself.