I've enjoyed my time with Objective-C very much. For consumer coding, I think it's very close to the safety/expressiveness sweet spot.
It was the first place (pre-ARC) that I learned to manage my own memory, and the first (pre-GCD) that I learned to be as safe as possible in a multi-threaded environment.
If in fact Swift is the death-knell of Objective-C, I will be sad. I've written C and C++ and Python and Go and Scheme and Lisp and on and on (Java, C#...) and it will remain one of my favorites for years to come.
Not academic research as in we did a study of developers who write iOS apps and determined that type safety as implemented in swift helps great developers write apps faster. (F# on the other than has a great type system that doesn't get in your way)
Choosing more type safety over less is a pragmatic concern - one input among many into the cost benefit analysis we all do when picking languages and platforms. More type-safe languages tend to have more boilerplate and hoops to jump through, but they also tend to be more robust. The latter can be proven theoretically more efficiently than with empirical research, but it is no less true for it. We are limited by the laws of mathematics, however 'pragmatic' we fancy ourselves.
Having never written a line of swift or ObjC, I have no opinion on the matter at hand. I also make my money out of the thoroughly unsafe Javascript. But it's not a good idea to blithely dismiss type safety as an ivory tower concern of academic CS. The benefits are real, and can be measured in the number of panicked pages/emails received at 3am.
I think it's worth hearing Linus out on the reasons you might want to choose a less type safe language over a type safe one.
Type safety is not the only good in a programming language.
PL is not an empirical science in that sense, it's more like mathematics. So your initial intuition about type safety, etc. is right on the money—that's the academic side of it.