The high-level goal is to make the availability/scale-out situation better. The feature will help HA setup where the master server needs to stop accepting WAL writes immediately and kick out any transaction expecting WAL writes at the end, in case of network down on master or replication connections failures.
For example, this feature allows for a controlled switchover without needing to shut down the master. You can instead make the master read-only, wait until the standby catches up, and then promote the standby. The master remains available for read queries throughout, and also for WAL streaming, but without the possibility of any new write transactions. After switchover is complete, the master can be shut down and brought back up as a standby without needing to use pg_rewind. (Eventually, it would be nice to be able to make the read-only master into a standby without having to restart it, but that is a problem for another patch.)
This might also help in failover scenarios. For example, if you detect that the master has lost network connectivity to the standby, you might make it read-only after 30 s, and promote the standby after 60 s, so that you never have two writable masters at the same time. In this case, there's still some split-brain, but it's still better than what we have now.
If there are open transactions that have acquired an XID, the sessions are killed before the barrier is absorbed.
inbuilt graceful failover for PostgreSQL
That doesn't appear to be very graceful. Perhaps objections could be assuaged by having a smoother transition and perhaps not even a full barrier, initially.