Now, developers have a first-class solution to connecting separate Storyboards files, in a Storyboard. This gives you the ability to scale the number of Storyboard files you have in your project. If you're having too many merge conflicts on the same Storyboard file, you can break up your Storyboards into more files.
That said, I'll concede and say that the single biggest problem with Storyboards is that it doesn't work well with text-based CVS, namely Git. Sure, fine.
...but, Storyboards offer a few HUGE advantages (all of which can't be replicated by anything else):
-Storyboards are the single best way to document your UI and application flow. If you do all of your UI implementation in code, it makes it near impossible to determine these things without following a 'run it and check it' approach. In Storyboards, you can visually see UI designs in a GUI environment, as GUIs should be displayed.
-Storyboards mean less code. You're not maintaining constraint objects and configuration details. All of that is contained in the Storyboards. In my all-Storyboards projects, I'd say the codebase is 15-20% smaller.
-Storyboards allow for quicker iteration cycles. You can align a button by changing a slider value, as opposed to tweaking a constant and continuously recompiling + running the actual app.
-Storyboards allow for more effective UI design. You can see your UI, as you design it. This, opposed to trying to take a design mock and blindly replicating it in code.
So, my perspective on Storyboards is that, if you're willing to sacrifice a certain amount of 'code review blindness', you stand to gain far more in the day-to-day and long-run of your project.