Ah, I thought I responded to ATM, my bad.
As I've described in the description of the jira the primary use-case is to allow JobTracker to be resilient to NN failures (hardware or software).
I did think long and hard about doing this in YARN, but with HDFS-HA this use-case is pretty much non-existent. Furthermore, since YARN isn't tied to HDFS as MR1 is; and since it's distributed across several AMs there is no single point of control like the JT in MR1. Thus, I think there isn't enough value in porting it as-is, conceptually (not code-wise).
In many ways this is similar to
MAPREDUCE-3837, i.e. no straight-backport.
Having said that, I plan to make sure we pay attention to this when we get around to fixing RM Restart. This is something I definitely plan to do later this year, at which point we'll ensure there is no 'feature regression'.
Eli's point about draining queues is a good one, I've opened MAPREDUCE-4575 and YARN-38 to track that. That feature is something we can do a straight-mapping conceptually across MR1 and YARN.