This is not the responsibility of the MacroCommand as it was designed. If the execute method were protected instead of final, then the likelihood of it being misused by not calling super is pretty high. You can always have the last command in the macro send the note that says it has completed.
One of the major points chalked against PureMVC by the users is the exponential explosion of classes when it comes to using the framework for executing a use case. Creating a command just for sending a single notification really can't be justified.
That's one of the major points chalked against any
OOP system. When I developed in Perl using the 'unified file theorem' (everything goes in one big honking file), I too forked the sign of the evil eye at full-on OOP languages like Java for this very reason. It's like a one man band vs an orchestra. Sure the one man can strap all those drums and cymbals and harmonicas to him and somehow make a coherent musical statement with it, but there's a reason orchestras are still around.
I'm not saying you need to have tons of classes just for the thrill of it. The goal is still to do the job with the fewest number of actors while still distributing the application's responsibilities amongst them in a sensible way. Many of the PureMVC applications I've seen rely far to heavily on Commands, one of the things that drove me from Cairngorm years ago, where there were always so many commands to write. Taking advantage of long-lived actors (Mediator and Proxy) that share a relationship while still decoupling the view components from the Model and visa versa, the number of Commands fell radically.
Also, just FYI, I rarely use MacroCommands except for startup, and even for that I often combine the View and Model prep into a single SimpleCommand. I just haven't found the need for them.