Technologically speaking, Guides have four major pillars of functionality:
1. Object “playlists” being flowed into reusable panel layout “slots”
2. Data Model-based, with binding to the external data file, and with model intelligence in an MVC architecture
3. Built-in navigation techniques to choose from
4. Form Bridge (communicating between a PDF and a SWF)
A subset, or specific instance, of 2) is the ability to extract the logic from an XFA-based form template and use it in ActionScript.
A subset of 3) would be the Question and Answer navigation control.
A subset of 4) would be simply having PDF displayed with the SWF, regardless of whether communication was necessary. The PDF might be a static, for-print, document.
Of course Guides, while giving one a quick Data Capture App from an XFA Form source, out-of-the-box, can also be customized into as rich an app as desired. Once you get the hang of it, there really is very little impedance to creating the App of your choice from a Guide-based beginning.
What is interesting to Development is whether the pillars described above should be available as independent entities in an SDK fashion, as opposed to being incorporated in a Guide app. The answer to that is obvious since it simply says to provide “more”. But the real question is that if those pillars were provided in independent, SDK-like, fashion, would you imagine your using them more than using Guide-Apps-as-consolidated-entities?