Typed notifications are exactly what the framework was trying to avoid. Believe me, I'm sold on the power of strong typing, but in this case, I wanted simplicity.
IMHO, Custom Events are such a pain to have to create if you want to throw a piece of data over to another actor. The actor has to be listening for the specific type and you have to create the class. Once you start making custom Events (or Notifications) its like the 'bet you cant eat just one' commercial; you end up with a plethora of them to manage. If you have a team and a codebase in flux, often code gets refactored not to use an existing custom event but the class remains, since other parts of the code use it, and no one knows when to get rid of it. You have to figure out what to name them, etc. In short it can become a hairball that is not even remotely worth the hassle.
In a system like Flash where you get a reference to an EventBroadcaster subclass and tell it to create a listener pointing to your method (which has a typed Event argument), typed Events make sense, in that the IDE can tell you something about the problem before you compile. The trade off (at least in flash.events.Event) is that you can't send arbitrary data with an Event. It just says something happened and here's the name of what it was and where it came from.
In the PureMVC implementation of the Observer pattern we trade that compile time knowledge of the type being sent and received for the decoupling of the actors (the observer doesn't need to know or have a reference to the subject, in fact the subject doesn't even need to exist at the time the observer is registered) and because of that we have a single inbound notification method that the notified parties receive their notifications on.
As Jason mentioned you can use facade.notifyObservers to send custom notifications, and feel free to do so, but I don't see the benefit. If you cast a received note body to the type you expect it to be, you still need to see if its null before making assumptions about it, do you not? Could you not have as easily as having got the type wrong, not loaded the body at all? Even if that body was typed, it could still be null. You can't catch everything at compile time, and this is one of those things that, again, IMHO, isn't worth trying.