kemsky, все равно не могу понять зачем общающемуся с сервером классу нужна слабая ссылка на DisplayObject =)

Про ваш пример. Я бы сделал (точнее уже делаю) так:
1) Все классы (вид, модель, контроллер и класс для соединения с сервером- ServerConnector) инстанцируются единожды
2) Инстанцировать многократно нужно только URLLoader (или его наследник ServerURLLoader). Для каждого запроса свой лоадер.
3) По завершению загрузки ServerConnector отписывает от всех событий объект ServerURLLoader и диспатчит нужное событие с данными сервера.
4) Контроллер слушает события коннектора и выставляет нужный флаг у модели и
5) лочит или анлочит вьюшку (MainLayer.lock() или MainLayer.unlock())

При необходимости, если все-таки напихали ссылок в ServerURLLoader на вьюшку, то делаем шаг
3*) вызываем метод ServerURLLoader.destroy(), который убирает все ссылки на внешние объекты.


Добавлено через 5 минут
Лично мое мнение, что если появились циклические ссылки, то архитектура проекта кривовата и утечки памяти, это только "первые звоночки" проблем которые появятся

Добавлено через 13 минут
Про советы от "адобе" =)
Коректнее было бы назвать best practices.
Это набор рекомендаций, которых придерживается значительная часть опытных программистов.

Добавлено через 39 минут
Углубившись немного в вопрос, могу сказать, что слабые ссылки можно применять для кэширования, которым нельзя управлять =)
Так что, даже это, лучше делать самому.
Тут в конце много интересных ссылок
http://c2.com/cgi-bin/wiki?CanonicalizedMapping