I like this proposal even more than the nLocktime feature. With Andriian's solution, there is no need to re-create the timelocked transaction after a certain period has passed. To invalidate the old one, you would have to spend one of the inputs thereby creating additional transaction costs. Not that big of a deal, but still. Or if you don't want to do that, you can create a timelocked transaction for a decade in advance, but you would be leaving your heirs waiting for a long time to get to the coins.   

But with Andriian's method, the sender would only need to create a new timelocked transaction if the receiver tried to broadcast it while the sender is still alive. In other cases, the sender only checks the status. That's good and it doesn't even have to be done that often. If the transaction timelock expires in one year, the sender would only have to check the status one time during that period.

But there are some negatives as well. No wallet uses Andriian's proposal. It only works in a testing environment and on a mobile wallet. If you wanted to use it, both parties would be required to use that one and only wallet. There is no desktop solution yet. Even if it was live on mainnet, it would have to be thoroughly checked and tested for bugs and vulnerabilities before being recommended.

But I hope he succeeds in creating this. It looks really interesting.