You can actually go one step further with your "Reason 2". Many may not realize this, but everything that you can do with the "bracket" part of Objective-C you can also do with straight-up C and the Objective-C Runtime methods.
In terms of size, they're almost the same (Objective-C classes are implemented with structs). In terms of speed, the difference is absolutely huge. You can generate a random number faster than you can make an Objective-C call.
But, it's fast enough for 95% of things people do with it.
Actually, that's on an iPhone. Here's the article for OSX from the start of 2008 (two months before your link), where the cached message call comes out faster than the virtual calls, and the non-cached is ~ 4.5x slower instead of ~ 2x on the iPhone:
Exactly. Many of the benefits of Obj C's dynamism come into play with the UI, where the main speed constraint is the response time of the user. And whenever you need to write compute bound code it is easy to drop down into C.
One of these days I will write a detailed account of my experience learning Obj-C, but for now I'll say this:
The fact that Obj-C takes C and adds objects on top is its biggest flaw, just like with C++. Worse than C++ though, Obj-C doesn't even attempt to fix at least some of C's more glaring flaws... you get the whole language, quirks and all.
I think it depends on what you want from the language. If you want to write C and gain some safety through the use of the message-passing abstraction, it's perfect. If you want a real high-level language, it's lousy.
With clang, ObjC is getting very interesting features that take it closer and closer to "real" high level languages, like GCD, ARC and blocks.
I'd still like more type safety, but the evolution there is slower and would need more fundamental changes to the language and abandoning C compatibility.
I dunno--in an age where we have actual, halfway decent garbage collection, referring to ARC as something that might compete favorably with those "real" high level languages makes my eyes go a bit crossed.
People in 2011 lose weeks to tuning allocators and collectors in real high level languages. C programmers take a memory profile, deploy the appropriate pool/arena allocator, and get on with their job, comfortable with the fact that their former allocation bottleneck is now in the average case register-fast.
ARC fits better with the C world of quickly tuning bottlenecks to register speed. Have you ever debugged C code with custom object lifetimes under a garbage collector? It's a nightmare.
People in 2011 lose weeks to tuning allocators and collectors in real high level languages.
But that's, statistically, almost no people out of 'people who use GC'. There aren't that many allocators in common use that even have much in the way of tunable parameters (I can only think of the JVM ones, offhand), the people who spend weeks tuning them have very particular needs - high throughput, low latency, high-enough complexity to warrant a high-level language. These are the sort of people who also do things like start at a PHP page and end up chasing performance improvements in the bowels of a network kernel driver. It's done, but it's unrepresentative.
ARC fits better with the C world
It seems like a much more central reason ARC is more suitable than a GC for Objective C than 'GC tuning is occasionally a dark art'.
What can I tell you here? You're right, of course: most apps don't care about performance at all, either in space efficiency or time efficiency. Those apps shouldn't use C, and should certainly use a GC'd language.
I'm only reacting to the idea that (pp) "because it's 2011, nobody should be using ARC". Well, a statistically tiny number of apps may require the bare-metal performance that hand allocation provides, but they're also disproportionately important apps.
Ah, I read it more as 'It's 2011, where's my flying car/why aren't just about all apps running in managed environments'. Sort of like one says, 'It's 2011, why did syslogd just brick my server'. And it's not a completely lisp-machiny, neckbeardy sentiment, 10 odd years ago everyone was telling us the flying car was just around the corner - Apple was busily trying to bridge Java into Rhapsody, Microsoft was working on .NET/CLR. And yet, and yet...
Or you could pick a well thought out OO language like Java or C#, maybe even Python. Unfortunately you're trapped using the abomination for iPhone development unless you pick Monotouch.
Not even Java's fans would defend it as a "well thought out OO" language.
Since this is Hacker News, it maybe appropriate to point out that nothing prevents you from building whatever specific flavour of OO you want on top of the Objective C runtime, if you want it badly enough.
I would not call Python a well-thought out OO language. Its OO is essentially a cranked up dict; the abstraction over the dict is just barely papered over. It can get pretty awkward.
Reason 1: When you need what C provides, it is right there for you (being a superset of C)
Reason 2: When you need what C does not provide (basic reflection, generics, polymorphism, whatever) it is in the "bracket" part of Objective-C.
Reason 3: The two above do work quite well together - the impedance mismatch is minimal, compared to e.g. Python with extensions written in C.