I think it's easy to forget that Objective-C has simple syntax for synchronized code analogous to that of Java (although not quite as flexible as Java's - we can't make a whole method synchronized simply by adding the keyword to its declaration for example). A lot is made of Objective-C's syntactical shortcomings, but little of its wins.
self in that context would be the class. The issue he was facing is that in subclasses, "self", would refer to a different class and therefore the lock wouldn't apply. What he's pointing out is that he resolved that issue by specifying the superclass explicitly.
Personally, if I had to ensure synchronous calls to a class variable, I'd prefer to just restrict calls like this to a specific queue using dispatch_sync().
dispatch_once(3)[0] can be used for lazy initialization without concern for the calling class and without synchronizing on a shared object. This is (likely) cheaper in most cases then entering a @synchronized block.
Yes. In general, either GCD or lower level atomic ops are a better choice for thread-safety than @synchronized blocks. Just pointing out that there are reasons other than global mutable state for wanting a critical section in a class method.