Dot syntax isn't so evil. Even the example of setting a property on a view's frame seems slightly contrived in that the compiler will give an error. It doesn't silently fail or do undefined things. The primary confusion there is, when you're new, wondering what in the world the strange error message means - but that's something you eventually get over as you learn more about the language and how it works.

Also, dot syntax is how you reference properties when you're doing KVC and KVO, so it wasn't without precedent.

"Likewise, we know exactly what this line of code does: a = b + 5;"

It could easily be unification or checking for equality depending on the language. Or it could be an assertion.

"Except for dot notation doesn’t do the same thing in Objective-C as it does in other languages."

And ='s doesn't do the same thing in objective-C as in other languages. (Although it does mean the same thing as in other C languages).

If you treat structure access as nested method calls, and then understand that certain methods do not have setters, this is a non-problem conceptually.

It is just a matter of knowing what methods can have get and set used on them, and which cannot. If you don't know that (and can't figure it out easily), I feel like you are SOL.

This argument seems silly when the world is already full of code like "self.view.frame" and almost any class uses @properties, which are very natural to access with dot notation.

Of course it's important to realize what dot notation actually does behind the scenes and use it properly. But I don't think that's so hard. The author just seems to be clinging to old ways out of stubbornness.