Про отсутствие ООП – наверное, имелось в виду то, что логично было бы разбить код на несколько классов (как минимум, вынести в отдельный класс работу с данными). А у вас всё в одном, что очень серьёзно затрудняет понимание кода и его дальнейшее расширение (наследование). Вернее сказать, в том виде, в каком он сейчас, ваш класс абсолютно нерасширяем, а это не есть хорошо.
Плюс – непонятные имена переменных (
bzhnc, например), кое-где отсутствует типизация. Ещё я не увидел геттеров. Сеттеры есть, а если я захочу сделать
picHeight += 20?
Также не радуют обработчики событий в 100 с лишним строк (
myEnterFrame). Как правило, такие методы можно разбить на несколько более простых, что существенно облегчит понимание и отладку.
А насчёт комментариев – может быть, сейчас для вас имена переменных и говорят сами за себя. Мне же, например, понять, что есть
arrUil01, очень сложно. И вам через полгода, уверен, будет не менее сложно. Поэтому комментировать очень важно, особенно если речь идёт о совместной разработке либо опубликовании кода. Причём комментировать как можно подробнее, особенно интерфейсную часть. Хоть и уходит на это чуть ли не треть от общего времени
Неплохой стандарт задаёт ASDoc, к тому же, можно автоматом доки сгенерить, а это уже приятно.
В общем, это действительно пока не компонент. Прототип компонента – да, но работы ещё очень много.
Только не обижайтесь, пожалуйста, на критические отзывы – вы же сами попросили)