If your components are chunky enough then it's understandable that you'd use RL to write them. I think I write stuff bordering on components in RL myself. After all - where does a component become a mini-application?
If we imagine that a 'component' could be anything from a textlabel to an xml-driven gallery - there is going to be a point in there where it's worth throwing RL in. I don't think you've done anything wrong in using RL to build what you have - especially if it has helped your code stay well structured!
There is no hard a fast rule, and as Shaun says - there right technology depends on the project at hand.
For me there are 2 good questions to ask when deciding whether to include robotlegs inside a 'component':
1) Does the 'component' need to be viable outside of the current project and highly portable?
- If the answer to this is yes then think carefully before tying it to the framework.
2) Does the 'component' need to make use of the command map, mediator map and injector mappings?
- If the answer to this is no then you could probably do something simpler - for example just use the sharedEventDispatcher approach and the eventMap (it's surprisingly easy to use parts of the RL framework on their own by providing their dependencies manually).
It's also oddly easy to rework written with robotlegs to remove the framework if you need to refactor it out later - if you've used the conventional MVCS approach and not injected into views and stuff anyway.
The difficulty can potentially come with version clashes between the RL framework in your components and the framework of the whole app. These should be minor but it's worth thinking about if you're packaging as swc - check your component against the various versions of RL to find out which is the minimum version that works.