Apple, for memory management issues, recommend defining outlets on properties, not in the attribute declaration. But, as far as I know, declaring properties exposes the class to external classes, so this could be dangerous.
On UIViewController we have the main view definition and the logic, so MVC is slightly cheated in this cases.
What is the beter approach, Apples's recommendation for memory-management or armored classes?
MVC isn't cheated by UIViewController, as that class implements a Controller. It defines connections between the View objects (usually stored in the XIB) and the Model objects (sometimes Core Data entities, sometimes other things).
Anyway. The point of defining outlets as properties is that you get to state explicitly what the memory management requirements on the properties are in the class interface. The NIB-loading mechanism uses the accessors if they exist, so you if you define a retain property, the outlet gets retained. If it can't find accessors it will set the instance variable directly.
Whether you define properties or not for your outlets is really a matter of personal taste. I do, because the outlets are set by an external object (the NSBundle class) so to my mind represent part of my view controller's API contract.
I believe you're thinking about this wrong.
Outlets only exist so that an external object, Interface Builder code and the nib decoders, can configure the instance of the class with the outlets. Hiding an outlet behind @protected or @private would defeat their entire purpose.
In good design this shouldn't be a problem because the view controllers should be relatively lightweight objects whose only function is to move data between the view and the model. The core logic of the app should be safely encapsulated in the model.
If you need a secure design, you can create the views programmatically and make them private but you lose all the flexibility and reuse that you get with outlets. It's a tradeoff.
In either case, however, this has nothing to do with memory management and properties. Whether a property is public, protected or private has nothing to do with how the properties memory is managed.