Of course container type classes, by their very nature, would probably favor composition (as Sho has stated in the 5th comment). Not alway true with control type classes. There is more than on way to skin a cat… And here is why:

Due to copious use of private and mx_internal APIs, accessing many aspects of a child component (i.e. composition) becomes nearly impossible. Obviously private properties and methods we can do nothing about, but some might say to go ahead and access the mx_internal aspects. I have done so, but Adobe even says, “This namespace is used for undocumented APIs — usually implementation details — which can’t be private because they need to visible to other classes. APIs in this namespace are completely unsupported and are likely to change in future versions of Flex.”.

Until Adobe starts making more of the private APIs more accessible by utilizing the other namespaces AND/OR solidifies their stance on future support for the mx_internal namespace, I am not going to write inheritance off just yet.

I think that inheritance is a viable strategy here depending on your needs. Imagine that I had an inheritance hierarchy that looked like this:

I don’t think there’s anything wrong with that, per se. I do, of course agree with you that composition is a better choice here, which is why I went down that path!