Good point.
There's an easy answer to that, which is that an installer is part of community AS and not part of the product. That's not very satisfying though. And I know Rich Sharples is interested in an installer-like capability, although in a quick scan I didn't that in any formal requirements doc. In the June discussions we had with Rich where we brainstormed a bit in that we didn't think about the QE implications though.
Another question is what does an installer really mean in terms of added QE and support burden. It's basically a tool for configuring the AS. So is the shell and a text editor; i.e. users have always been able to alter the AS "profile" and make it run a configuration that's not part of our formal test plan. So an installer doesn't add anything new there. What does seem new:
1) If we make it completely trivial to run a particular profile (e.g. we ship a domain-messaging.xml with a nothing-but-messaging profile, or include in an installer a single checkbox to create such a canned profile) then users could expect that we've quite thoroughly QE'd that particular profile.
2) Users might expect that the installer would only allow valid, bootable combinations; i.e. if subsystem X requires subsystem Y and socket-binding A, then a profile can't be created that doesn't include X, Y and A. Confirming the installer enforces that would be a QE burden.