Hi,
Remember that event_route[dialog:end] occurs at a rather high level of abstraction: dialog state. There are many reasons why a dialog can come to an end, and not all of them are brought about by a negative SIP reply.
The same is true of failure_route, but to a lesser extent. And since failure_route is a TM construct, it is easier to expose winning reply / last branch attributes into it for convenience. The dialog module uses TM callbacks, but ultimately is much more abstract than TM. You can't expect all state information to be available here. It may be possible, from a software perspective, to plumb it down into dialog event routes, but that doesn't mean it should be done.
My suggestion is to capture the replies you're after in an onreply_route or failure_route and correlate by SIP Call-ID.
-- Alex