Суть та же, все уже сделано, велосипеды от лукавого.
Сам спросил — сам ответил.

Ну вместо "передачи функции куда-либо по ссылке" напишите "подписка обработчика". Плюс т.к. как минимум обработчик может быть не один и просмотреть все обработчики нет возможности, то отследить. что происходит может быть сложнее.

Это написано после моего сообщения, и видимо относится ко мне? Не надо искать новых оппонентов, у Вас их достаточно. Я всего лишь пытаюсь развеять некоторые заблуждения, поделившись опытом. Вы конечно вправе цепляться за них, искать цитаты в мировой литературе, громыхать именами – я и сам так делаю, когда нужно. Вы для себя решите, что для Вас лучше: отстоять свою "правоту" или разобраться в вопросе и повысить скиллы? Потому что я как модератор не вижу диалога, вижу Вас в боевой стойке с выдранной из Мука страницей. Из Мука, которого большинство Ваших оппонентов прочитали и изучили не по одному разу, и не по десятку раз использовали на практике. Я советую Вам перестать огрызаться и начать разговаривать. Польза от этого будет Вам в первую очередь. А заодно и нам, когда мы услышим Ваши доводы и мысли.
Пока что было приведено три довода.
1) Удобство отключения слушателя для множества объектов.
Ну я показал, как это делается без костылей, стандартными методами ActionScript, созданными как раз для этого.
2) "то как реализовано у меня больше похоже на полиморфизм".
Полиморфизм имеет очень четкое определение, на него не может быть "похоже". Полиморфизм это когда объект одного типа может быть безопасно заменен объектом другого типа. Например в addChild() вы можете передать как Sprite, так и TextField. То, что Вы одну Function заменяете на другую Function, к полиморфизму никакого отношения не имеет. Поскольку в ActionScript отсутствуют шаблоны типов, функции не могут быть "типизированы", то есть их сигнатура не может быть гарантирована непосредственно, а только через интерфейс объекта-хозяина. Если в вашу кнопку передать метод, требующий параметры, произойдет исключение. И механизма контроля нет. Именно поэтому в ActionScript коллбэки нарушают ООП. В языках с шаблонами типов этой проблемы нет, и там использование коллбэков никого не напрягает.
Если хотите поддержку из мира ООП, ссылайтесь не на полиморфизм, а на паттерн Command (Action). Вот от него тут есть что-то))
3) Страничка из Мука.
Централизация не значит "коллбэки". Более того, централизация не значит "централизация всего и вся".
Есть (должна быть) иерархия, в этом суть ООП, в разделении на объекты с ответственностью. Вы пытаетесь всю ответственность отдать одному классу. Это сломает иерархию и все ее плюсы. В приложении должны быть выделены несколько модулей. Каждый отвечает за какой-то функционал. Допустим есть Меню, есть Статья, есть Галерея фоток. Каждый из этих модулей должен иметь свою специфическую логику, работая со своими частями. Главный класс вовсе не обязан знать все о картинках галереи и разбираться с их поведением. Он "общается" с Галереей, а Галерея управляет картинками. Вот в отношениях Галерея > картинки безусловно хороша централизация. Нет смысла вешать слушатели на каждую картинку, потому что действия идентичны. А если действия разные, централизация превращается в батарею свитчей и такие прелести ООП как повторное использование, расширяемость, абстрактность и полиморфизм исчезают навсегда. Пока у вас только кнопки, то есть все фигуранты одного типа, все нормально выглядит. Когда Мейн будет ловить и обрабатывать клики и от кнопочек Меню, и от картинок Галереи, вам никакая страница Мука не поможет, ибо это по ту сторону логики, и Мук туда не хаживал. Не цепляйтесь за буквы, выдранные из контекста.

Добавлено через 2 минуты
Пока писал, целую страницу накатали))
Рад что стало походить на диалог.

Прошу прощения - не скажу ничего нового, но все же замечу: как много тем на форуме (да и мною поднятых в том числе) напоминают анекдот про Шварцнегера и бензопилу (я уже по моему писал где-то). Странные люди упорно не желают использовать даваемые им инструменты как положено, а пытаются делать все через южное полушарие. В данном случае я про событийную модель.

И это хорошо.
Сигналы - это тоже альтернативный велосипед. Правда списанный с сишарп и QT.
Но ведь хороший велосипед.

Странные люди ищут более простые решения для конкретных задач, только и всего. ООП хороша для сложных систем, но как все универсальное и при этом безотказное – слишком сложна и избыточна. Событийная модель в том числе: гибкая, но оттого же и тяжелая. Чаще всего мы не используем и десятой доли заложенного в ней функционала (как и во многом другом). Люди ищут варианты без лишних фич, это нормально. Кто-то использует мегабайтные сторонние библиотеки чтобы загрузить и вывести картинку на экран, и это тоже нормально)) Главное понимать, что и зачем, а не упираться рогами в концепции.

Но дело в том, что события зашиты в плеер и если мы будем использовать кастомные решения мы никак не выиграем ни в весе ни в скорости (хотя в скорости иногда можно выиграть всё-же: в блоге wvxwv есть его велосипедные сигналы, и они, вроде как, быстрее даже)

Ну да, но это поиск, и результат не малого опыта и временных затрат. Я говорю о том, когда мы явно пытаемся обойти очевидное решение, исходя из чисто теоретических соображений. Я сам неоднократно так делал, но редко когда оправдывал свои подходы, если они при этом, будучи примененными мною на практике, они не давали явной выгоды. Нафантазировать-то можно все что угодно.

у меня кнопки нажимаются мышкой, одновременно можно мышкой нажать только 1 кнопку (потому что только один курсор). Различия скорости выполнения в наносекундах в данном случае не критичны

Мне вот больше интересно другое.
Мы в кнопке подписываемся на клик, чтобы вызвать метод, который передали в кнопку по ссылке.
А почему нельзя сразу подписаться на клик с нужным методом?