It's definitely true of the iApp framework that if an iApp template creates objects that those objects can only be manipulated using the iApp framework (unless you disable strictness). However, that's somewhat contradictory to another goal of the iApp templates which is to ask as few questions as necessary - otherwise one ends up implementing the entirety of the UI elements corresponding to these objects all mashed together in an iApp - it's at least messy, and in some cases impossible if the iApp framework doesn't support what you want to do. So if we don't include enough options for you in the template, but we also don't let you change them by hand, then what do you do? I see what you're getting at.
Basically when we (F5) design templates, we take a good look at what the majority of customers will want to do and we expose those options in the templates. We are actually in the process of creating a second generation template for many of the current ones that we ship that do a better job of this as we have gotten good feedback about it, have reviewed support cases, and have reviewed customer configurations provided via iHealth. We might release some of those on DevCentral early prior to them shipping as part of TMOS. We also recognize that there is always going to be someone that needs to get at the options outside of what the iApp allows. To handle those situations, we allow for an advanced user to create a profile/pool/snat/etc outside of the iApp framework with arbitrary options configured, and then to reference those objects in the template in order to accomplish the desired configs. Some of that behavior is available already in our templates, and we're adding more of it to the ones that we're working on right now.
We generally discourage customers from disabling strictness on iApp services for the reasons that you list - it basically makes the situation unsupportable and the behavior unpredictable from template to template depending upon how it is written. Sometimes changes made outside of the iApp once strictness is disabled will make it through a reconfiguration of the iApp service - but sometimes it won't. It totally depends upon the iApp, but uncertainty like that is bad for stability and reliability.
If you find that the iApps don't expose enough options for them to suit your needs, then it might be that we need to add some options for you (or that you should do it yourself if that works for you). I hesitate to add that that you might not be a good fit for iApps due to your environment or how you need to use the product but it might be the case as well.