And there’s nothing wrong with that, but, I’ve seen some devs these days spend waaay too much time on “making it simpler” or whatever their ideal is, at the cost of error handling or you know, solving an actual problem. Personally, I don’t care what the code looks like as long as it’s resilient in the face of unexpected errors (ex: a user input of 0 to a division function is not “exceptional,” you should have anticipated that, while a service input of the same may be a breach of contract between the services and IS exceptional) and actually solves a problem.

You're contradicting yourself here already.

Resilient code is easy to read/grasp code. It should pass a 3 am test too.

I really think you're wrong to say there's no tradeoff here. Error handling makes code bigger and harder to read.