Unfortunately, my day to day language at work is Go.
The userbase of Objective-C was much smaller before OSX brought Cocoa to the Mac ecosystem.
> The fact that things are shorter to declare doesn't make it better.
This is debatable. In fact, shorter code could (but not always, of course) mean less room for error and more room to hold higher abstractions. Boilerplate is a less efficient use of cognitive energy.
That's not a hard and fast rule. There are obvious inflection points. A 200 character long identifier is less readable than a 20 character identifier in almost all cases. A 1 character identifier is less readable than a 8 character identifier in almost all cases. Somehwhere between those extremes is the sweet spot, and it's likely somwhat different depending on person.
As for language keywords, as long as they are unique, unambiguous, and not likely to conflict with written code often, shorter is likely better since it's purely a matter of learning them when learning the language. Given those constraints, it's easy to see it's possible to be too short though (any single character keyword that is not context sensitive is likely a horrible choice).