While I'm on the subject with at least one reason why Starling's EventDispatcher cannot extend the native one (at least not without major headaches), let me share a few more.
1) An extended EventDispatcher will not be able to dispatch a plain flash.events.Event in some situations. This will require appropriate runtime errors, documentation, and forum support to ensure that developers understand what is going on. Most people should get it, but there will be some that get confused. This one may be minor, but it's also not free.
2) The native EventDispatcher internally clones an event that bubbles. This can cause excessive CPU usage from object allocation and garbage collection, which hurts performance. It also makes it impossible to use pooled events when bubbling. I'm just repeating this one so that it doesn't get missed by anyone scanning through this topic who might miss my previous post.
3) The native EventDispatcher doesn't have removeEventListeners(), and there's no way to access the internal list of listeners using ActionScript. If this method is to continue existing, you now need to manage a duplicate list of listeners when addEventListener() and removeEventListener() are called. That requires more memory, which may or may not be acceptable.
Additionally, for listeners that should use a weak reference, you're in trouble. You can't simply put them into an Array/Vector like normal listeners. The only way to store weak references in ActionScript is using a weak key in a Dictionary. As I recall, there is a bug in the runtime involving using functions as weak keys in a Dictionary. I don't remember the details for sure, but I think Grant Skinner referenced it in an old post from 2006 (quoted for convenience):
Note that there is a known bug with Dictionary that prevents it from operating correctly with references to methods. It seems that Dictionary does not resolve the method reference properly, and uses the closure object (ie. the "behind the scenes" object that facilitates method closure by maintaining a reference back to the method and its scope) instead of the function as the key. This causes two problems: the reference is immediately available for collection in a weak Dictionary (because while the method is still referenced, the closure object is not), and it can create duplicate entries if you add the same method twice. This can cause some big problems for things like doLater queues.
Last I heard, this issue was not fixed.
We could make weak references unsupported, since the current custom EventDispatcher doesn't support them either. This will require appropriate runtime errors (or maybe a less critical warning of some kind), documentation, and forum support.
The alternative is to remove the removeEventListeners() function. However, that cannot happen without breaking real-world code. Starling has broken code sometimes, sure, so maybe that's okay. I think we're reaching a point of stability and community size where that can't happen as often anymore, though. It depends on the ultimate impact, I guess. The dispose() function on every Starling DisplayObject calls it. It means that people expect those listeners to be removed automatically for them! It's bound to break things in ways that may be very difficult to track down (which leads to more forum support... which can't be brushed away because it's really quite time consuming). Additionally, I've seen many Starling developers use removeEventListeners() in posts here in the forum. It's obviously convenient and useful to many. They're not going to like it being removed.
With that in mind, it may still be possible to remove it later. Perhaps in a Starling 2.0, since breaking changes like this are often more acceptable in major versions. However, as I said, this function is also very convenient. At least some portion of the community won't be happy with its removal. At the very least, it will require obvious documentation, and, of course my old friend, forum support.
There may be additional issues, but those are the ones I can remember right now.
EDIT: Adding more as I think of them.
4) Starling event listeners can accept 0-2 arguments. The native dispatcher can only work with listeners that accept exactly one argument.
function listener():void
function listener(event:Event):void
function listener(event:Event, data:YourTypedData):void
Removing this ability will break existing real-world code with all the same issues as removing removeEventListeners().
The Event data property is related to the Starling event pooling feature. Event subclasses can't take advantage of pooling, so a generic data property allows you to pass in arbitrary data to include with the event. Accessing it from the Event object requires casting, but the listener is able to add a typed second argument to avoid the need to cast. It's really quite nice.