Dealing with frame/bounds, spacing/ratios etc etc has no place in a view controller.
I agree. It belongs in a view.
Code I write should be tight, functional, and useful.
This argument is a logical fallacy as it suggests that manually written UI code is not tight, functional or useful.
Tons of boilerplate code that is heavily repetitive/easily generated by a machine (see swift 4's codeable) up until it needs to be modified (say I need to bind a label's color to a state/action dispatch, then you need to hook in).
The problem with this argument is, that taken to its logical conclusion, people shouldn't be writing code: Code should be writing code. And to be honest, I agree. I mean, what 5-10 years before machine learning / AI is applied to software engineering and we're all out of a job.
As for fear, that's all I've ever seen: people afraid of using storyboards for "reasons" they can't really expand upon when challenged.
Challenge accepted.
Storyboards don't play well with version control as they are not consistently laid out. So, if you have more than one developer, you need to have particular ways of working to avoid merge conflicts and corrupted files (it's the same with Xcode project files, or CoreData files).
Storyboard are slower and use more memory than code, as they have to be read into memory from disk, deserialized, validated, then translated into code, and executed.
Storyboards are, at best, a partial solution. You will almost always have to write code to make a view functional, unless it's the most basic view thinkable.
Storyboards SUCK for peer review, as XML is infinitely less readable / reasonable than code.
You cannot create custom initializers if you are using Storyboards (specifically segues) as you are not the one to initialize a view controller. This makes isolation and dependency injection impossible.
There's more, but I've had an ale, so...