ОК... коллекции, и почему они не должны (не обязаны) быть во flash.collections.*. Если вы посмотрите на Java / C# - коллекции тоже не являются частью языка, а частями фреймворков, EE / SE - в Java или .NET соответственно. Просто в этих языках все привыкли к тому, что вендоры пишут низкоуровневые фишки оставляя реализацию програм уже самим пользователям фреймворка, и грань между тем, где заканчивается сам язык, а где начинаются библиотеки немного размыта. Во флексе это возможно было сделать точно так же, но из необъяснимых стратегических соображений это не было сделано.
ArrayCollection - это просто классика жанра в этом отношении.
Итак, для тех кто не совсем в курсе событий. ArrayCollection наследуется от ListCollectionView (единственной коллекции существующей во фреймворке - все остальные, это ее потомки в том или ином виде). Все, что она добавляет поверх ListCollectionView - это сериализацию в... Array! А теперь рассмотрим пошагово зачем это нужно.
Мы тут обойдем стороной спор о том плохо ли хорошо ли ORM, мы просто предположим, что мы души не чаим в ORM и поэтому мы хотим сериализовать ArrayCollection на сервере и отправить ее уже в готовом виде клиенту.
Типичная реализация фейк-класса нужного для сериализации ArrayCollection - отнаследоваться от ArrayObject (PHP) и ничего кроме этого не добавлять / не убирать, т.е. просто создать ArrayObject2 - полную копию ArrayObject. Оп-па - выстрел в пятку! Ну ладно, можно это чудо запихать в секретную директорию и не показывать пэхапэшникам от стыда подальше. Дальше, получили мы это чудо на клиенте - оп-па, и снова пальцы в двери, это ж весь датапровайдер надо поменять - все ссылки на него порушить и т.д. - прям плакать хочется, это ж сколько работы пропало. В итоге, почесав репу, удаляем PHP фейк, посылаем из сервиса массив, ресетим соурс на клиенте и радуемся жизни - и вот он момент истины! - мы опять открываем сорцы ArrayCollection и понимаем, что ту единственную функцию, которую она добавила к своему родителю мы как больше всего и не хотим использовать! А все потому, что кроме всего остального присутствует неразбериха в названиях ArrayCollection ни разу никакая не collection, это обертка, view, ее вообще протовопоказано сериализовать!
Дальше идем читаем блоги посвященные Флексу и тихо радуемся жизни
Что до UIComponent и life cycle - если вам нужна совместимость с не-фреймворковским кодом, даже рассматривать этот вариант смысла нет. Опять же, идея цикла компонентов не новая, она просто очень плохо скопирована со старших братьев - WPF / SWing ну и, в лучших традициях, со своими изюминками - типа "внезапно" создать два экземпляра вместо одного, или так же "внезапно" забыть вызвать какой-нибудь из методов, или "внезапно" у всех событий испускаемых этими компонентами будет по 2 инстанса (а че, жалко чтоли?) да еще и capture фаза (а чеб нам его стейджу или руту не задиспатчить, чтоб он там не расслаблялся?). Хуже всего то, что последнее вовсю эксплуатируется в MATE / SWIZ, и когда обнаружилось, нашлись поборники этих библиотек, которые уговорили это не менять мотивируя тем, что на их библиотеки это плохо повлияет, а остальные все равно не догадаются.
Еще из любимых внезапностей флекса - это уйти в бесконечную рекурсию валидаций, особенно часто случается со скроллерами, когда они то появляются, то исчезают нагревая ЦПЮ
Биндинг - это из серии "объять необъятное". Т.е. он по определению не может работать хорошо ни в каком виде никогда, можно долго замыливать глаза, дописывать десятки try-catch, но, в конце концов - облом. Ну вот так вот устроен язык, что нельзя в нем реализовать эту фичу, нужен либо другой язык, либо отказаться от затеи, третий путь по определению ущербен.
А вообще, все это беллетристика, потому что, не будь этого убожества, не было бы и притока новых программистов в AS3, и даже и тех куцых разработок, которые есть сейчас - тоже не было бы...