This is going to sound like waffling.
In iOS programming the answer is clear. backgroundColor is a property so although the first two snippets are equivalent I would always prefer self.window.backgroundColor to using setBackgroundColor.
In Mac OS X programming backgroundColor is not a property. I would love them to retrofit these classes with properties that are accessible to us. So in that case it is technically correct to use setBackgroundColor although because of the naming conventions the dot notation will work.
I asked an Apple engineer (you’ve heard of him but I haven’t asked his permission to attribute this to him) how he felt about this misuse. He said that this is fine and implies the right thing since there are backgroundColor and setBackgroundColor methods. He did want to make sure that I never used the same sort of shortcut for methods that obviously were different than properties.
So if you have a method with declaration -(void) doSomething, you still could technically call it using self.window.doSomething. This would be wrong as it would imply the wrong thing. If you are sending a message to an object you should use [self.window doSomething], if you are getting or setting an (let us say) informal property you can use self.window.backgroundColor.
By informal property I mean a pair of getter and setter methods that are clearly backed by some ivar.