Почему выбрал именно масштабирование, объясню....
Карта приближается и отдаляется плавно... соответственно если менять координаты отметок в не масштабируемом контейнере, то они как бы будут догонять свои координаты....отставать , причем визуально видимо...
Если же эти отметки лежат в масштабируемом контейнере , где их координаты постоянны... то придется менять их масштаб обратно пропорционально масштабу карты.

Поэтому в каждом есть событие onEnterFrame ...для изменения масштаба....

Может не рационально... тогда подскажите как разгрузить систему от onEnterFrame .

Зачем вам вообще нужен это onEnterFrame?
Организуйте без него. Ведь есть же событие, при котором вы масштаб карты меняете? При этом же событии и пересчет меток делайте.

Добавлено через 56 секунд
Вы это проверили или как...?

Вот посмотрите пример.
Там нет onEnterFrame.
Масштаб меняется с кнопок и с колесика мыши.
По желанию плавного увеличения/уменьшения масштаба с кнопок можно переделать изменение масштаба не пошагово, а через интервальную функцию и событие кнопки onPress.

Ну вот еще вариант не РАЦИОНАЛЬНЫЙ придумал)))
Вообщем у вас какое то событие Resize ( или функция) при которой меняется масштаб - если он вдруг меняется, то удаляется 1 клип, на место него ставится 2й.
Все это происходит после зума, кстати проверь вложенный клип после зума будет ресайзится вообще или нет - если нет то че парится то! Аттачи все время тот же клип а потом удаляй и снова аттачи при ресайзе.

Оригинально, но...
А если у него плавно зум идет, например, с колесика, меняется масштаб раз 3-10 в секунду. На карте, допустим, 20-100 меток.
Значит в секунду от 60 до 1000 циклов удаления-аттача... Может, конечно, нагрузка и не такая сильная будет и соизмерима с перемасштабированием.
Но я все-таки остаюсь за вариант простого пересчета-передвижки координат меток во внешнем мувике.

Но я все-таки остаюсь за вариант простого пересчета-передвижки координат меток во внешнем мувике.*** да это и так понятно мой друг. Но ТС то че делает придумывает велосипед! Вот мы ему и помогаем велосипед сделать! разными способами)))

Кстати, по поводу аттача. Не годится, т.к. после аттача в мувик карты эта метка точно также изменит свой размер сообразно масштабу родительского. И к тому же координаты для аттача все равно надо пересчитывать. Но первая причина делает вообще дальнейшие действия бессмысленными.

На момент скролл, я бы вообще снял битмап и матрицей менял его размеры, чем гонять ресурсоемкий вектор. После остановки скрола строил бы новую карту из вектора.

Так? :
1. Делаем один шаг масштабирования (например, колесико делает одну дельту)
2. Читаем битмапу карты.
3. Пересчитываем размеры битамапы с помощью матрицы с учетом дельты.
4. Отрисовываем из новой битмапы вектор в мувик обратно.

Такие циклы, также 3-10 раз в секунду будут ли менее ресурсоемкими?

Не так. Вектор показываем только после n секунд после прекращения зума. Точное значение получаем в результате тестов. При чем, если позволяет технология, отрисовку вектора начинаем от центра зумирования (курсора).