Проще говоря, тот контейнер, в который Вы что-то добавили, сам должен быть в списке отображения. Технически, естественно, у каждого контейнера есть как бы СВОЙ список отображения и возможность им управлять. Но на экране плеера будет показываться только тот объект, ВСЯ цепочка родительских списков отображения которого доходит до stage (собственно экрана). Я уже использовал слово "вложенные". По аналогии с: есть Дом, в нем есть Квартиры (одна или несколько!), в них есть шкафы, в шкафах есть ящики, в ящиках шкатулки. Так вот шкатулки находятся В ДОМЕ. Так понятно? А если шкатулка в шкафу, а шкаф на даче, то В ДОМЕ она не находится. Она в списке какого-то Шкафа, но не в списке Дома, потому что этот Шкаф НЕ в списке Дома.
addChild() это метод Списка Отображения. Child это "ребенок, потомок", а parent это "родитель". Имеется ввиду "ребенок" и "родитель" только в Списке Отображения. То есть, родителем объекта может стать совсем не тот объект, который его на самом деле СОЗДАЛ оператором new. Новый объект может быть создан одним, но добавлен в список другого объекта, который и будет его parent. То есть parent это не обязательно создатель, скорее хранитель, опекун или просто контейнер — банка, в которой лежит объект. У него есть свой parent, у того — свой, и так вплоть до stage. У ребенка могут быть свои дети — но только если он сам является наследником контейнера (класса DisplayObjectContainer), то есть мувиклипом или спрайтом (или их наследником). Шейп и ТекстФилд не имеют собственных списков, не могут содержать детей. Соответственно у них нет и методов Списка.
Есть также терминология Дерева. В Дереве веткам соответствуют контейнеры, а листьям — не-контейнеры, конечные элементы списка, которые не могут иметь детей. Поэтому концепция Дерева больше подходит в данном случае).
Контейнеры абсолютно прозрачны. Даже мейн. В редакторе Вы задаете цвет рабочей области, но это не часть мейн-класса. Это цвет stage, цвет окна плеера. Если Вы загрузите такой ролик в другую swf, то увидите, что он прозрачен, мейн не закрашен никаким цветом. По сути контейнер это математическая категория — система координат. Для простоты его можно рассматривать как прозрачную папку, или банку. Все, что "внутри" — перемещается вместе с самой банкой, и масштабируется, и поворачивается вместе с ней. Но правильно было бы думать об этом как о системе координат.

[holy war mode on]Суперзис головного мозга. [holy war mode off]

Добавлено через 1 минуту
Если нельзя, но очень хочется - то можно.

А технически могут возникнуть ситуации, когда это влияние на код окажет?
А то ведь бывают ситуации, когда пишешь this, хотя в самом классе метод не переопределён.

Есть поверье, что написание this и super помогает понять, что этот метод был написан в суперклассе, а этот переопределён.. ну и ещё какие то непонятные мне оккультные аргументы.
Но даже придерживаясь этих суеверий надо придерживаться их до-конца :)

Согласен, сначала я думал, что поможет только мне понять, но потом понял, что и код легче понять.
Но вчера вечером я писал код, который сразу мне напомнил эту тему.. Супер класс унаследован от Sprite, в нем addChild не переопределен, но в его методе написано this.addChild, ведь в момент создания объекта унаследованного от этого супер класса, this!==SuperClass, а this===SubClass, в котором метод addChild переопределён. Вот я и уточнил, может ли это как-то отразится на работоспособности. И про addChild я выдумал, так-как там другой метод, но объяснить легче было так.