Что реже вызывается, то и меньше грузит. Это не очевидно?

Визуальную анимацию ВСЕГДА лучше делать на EnterFrame. Этот ивент, в общем-то, для этого и предназначается. Таймер же в этом случае - лишний объект с лишними диспатчами ненужных ивентов.
В твоем случае лучше сделать один глобальный обработчик EnterFrame для stage, например, и в нем в цикле двигать все объекты. Если тормозит, можно попробовать снизить фреймрейт, но лучше удостовериться, что все объекты совершенно примитивны, то есть на них нет своих анимаций, не навешаны никакие листенеры, не прописаны никакие скрипты, не изменяется альфа и что все они cacheAsBitmap.

EnterFrame желательно использовать 1 на всех, а не каждому 1

Неправда, как вы сделаете, если нужно что-то двигать толчками или наоборот - очень быстро, быстрее, чем fps? А как вы сделаете анимацию по времени?

Циклом.

КорДум А зачем делать анимацию быстрее фреймрейта? Отрисуется же всё равно по фреймам.

Aquahawk
Скорее всего он имел ввиду смещение маленькими шагами на большие растояния. Не для анимация, а для определённых проверок. Например не пролетела ли пуля тоненькую стену.

Честно говоря, не понимаю пристрастия к таймеру для реализации анимации.
Таймер:
а. сможет послать событие только в общем потоке. Т.е. опять же после ENTER_FRAME.
б. вследствие этого не точен.

Единственный сомнительный смысл в нем, если он сможет выполниться несколько раз за фрейм. Но тут опять же:
а. придется вызывать updateAfterEvent, что форсирует и без того самую затратную операцию — рендеринг.

По мне у таймера есть единственное применение (причем прямо ему присущее): через n-е время послать событие, а уже по этому событию запускать анимацию и т.д.

Как-то так:
Если же надо проверять коллизии, то очевидно надо проверять не только текущее положение объекта, но и его траекторию между кадрами.

Что мешает заранее просчитать не пролетит ли пуля через тоненькую стенку. Без таймеров, реального смещения и всяческих хиттестов.