We've done this on a couple apps, and I think it worked well.
This biggest pain point I remember was that UIScrollViews need to be told their contentSize, which I didn't find a good pattern for our interaction designer to use. I believe she ended up just going with one size fits all, and on screens with less content there was simply a big blank space at the bottom.
The alternatives were a custom controller per scroll view, or have the controller inspect the view hierarchy somehow, making it more complex.
It can certainly get unwieldy if you add lots of screens, or have complex navigation flows.
Perhaps you could use a table view with static cells (even just one cell with everything in it) instead of a scroll view in most cases. With container views, you can make the static table view a subview of another controller easily now, too.
This biggest pain point I remember was that UIScrollViews need to be told their contentSize, which I didn't find a good pattern for our interaction designer to use. I believe she ended up just going with one size fits all, and on screens with less content there was simply a big blank space at the bottom.
The alternatives were a custom controller per scroll view, or have the controller inspect the view hierarchy somehow, making it more complex.
It can certainly get unwieldy if you add lots of screens, or have complex navigation flows.