Sorry for the sooo late answer to that...
the idea behind this rule is to promote the usage of Presentation Models. A view should only have as an entry point a PM, everything else required by the view should be injected through the PM and consumed by the view then by bindings.
A common problem we've identified with multiple entry points in views is that:
1. The order in which the parameters are set can change the behaviour if the validation/invalidation pattern has not been properly implemented
2. Injecting the dependencies through a PM can somehow give developers on Binding execution. i.e. having multiple entry points could potentially trigger bindings several times. If everything is in a PM then Bindings will trigger only when the PM is injected.
sorry that I don't understand, but this reply seems to miss the point made in the original question. Why is it OK for the flex components to have an almost limitless number of variables, like for instance:
<mx: Button id="button1" label="button one" left="30" verticalCenter="0" click="somefunction()"/>
but if we try to build one ourselves, more than one variable violates some guideline? It looks like ALL flex components need intensive refactoring which seems unlikely, so I have probably missed some essential bit of information/education. Please clarify a bit further?
I agree with Xavi's previous reply, you also raised a good question: Why does not it apply to the SDK?
You don't build an application like you build a SDK.
You do have some business logic in you application, whereas the SDK team does not have any business logic to deal with.
The rule is more a guideline, that you can bend if you need to.
If you append to build a SDK for other developpers on top of the SDK, then I would disable that rule.
But again, all the points mentioned by Xavi are absolutly right.