The "representedObject" is part of that new code that Apple has bolted onto NSDocument to make it more appealing to iOS developers. Or perhaps, it is UIDocument that Apple has hacked up to work with legacy NSDocument app. I don't know which.
But I can tell you that the representedObject is just a convenience. Apparently Apple wants people to have a more strict separation between the document object and the user interface in Interface Builder. This could be Apple's take on MVC, or MVVC, or MVVDCFDJMMMC. Just the fact that Apple created a class called "ViewController" means they had no clue to begin with. Building complex OO architectures was never Apple's strong suit.
Bindings, however, are a nice convenience. They "bind" user interface attributes to properties in an object. Instead of manually setting a text value or manually disabling a control, you can bind them to properties. Then, in your code logic, just set properties and the UI gets updated automatically. The only trick is that you can only update the UI on the main thread. That means that you can only upate a bound property on the main thread. Otherwise, bindings are pretty slick.
I do think that your biggest problem is related to state. You are making too many assumptions. You can't assume that your user interface is is ready and available to display your data when you load the data. You also can't assume that you have any data when your are displaying your user interface. You can't assume that your app has been initialized when you load documents. You can't assume that all documents are available when you initialize the app. Make sense?
The app lifecycle does not necessarily run in conjunction with document object lifecycle. The creation, initialization, and initial display of documents is mainly handled by the framework on its own schedule. That makes it a challenge when the framework dips into your code and you have assumptions about the UI and the document object. It gets really tricky when you start looking at the end of a document's lifecycle. Document objects are intimately tied to their windows and may never be directly released. This is where the "representedObject" could be useful. You could control this object very precisely and then let the framework do whatever it is that it does or does not do with the object.
See janabanana's excellent advice. The only part I would disagree with is the idea that using NSLog makes one a "simpleton".