I would like to understand the rationale behind this. This behaviour currently prevents the generation and signing of transactions on an offline machine that can then be later broadcasted to the network.
There are three main considerations at play
1) it's a way to augment proof of stake consensus with a form of TAPOS. While transactions are not used as a chain selection rule, they do leave a forensic trail that can be used to differentiate between the real chain and fakes.
How valuable this is depends on how paranoid you are about weak subjectivity.
2) it creates solidarity in the case of long reorganizations. If a 51% attacks were to trigger a double spend, it would also have to revert most transactions creating a lot of disruption. This makes it more likely that a fork is initiated out of this bad situation than just a shrug.
3) it prevents reliance on long term support of the binary serialization of transactions which can be an expensive backward compatibility to maintain
If you want to sign time offline and broadcast later, you can do that with a smart contract and the
The idea is just that, when you create a transaction, you might have expectations on what already happened on the network. Including a transaction hash prevents including the transaction in a fork where these expectations are not correct (some former transactions didn't happen).
Note that you can include a transaction in the 64 blocks after the hash, so it shouldn't be a problem for offline signing, you have one hour to take the hash, sign the transaction offline, and broadcast it on the network.
From the white paper, "If an attacker ever succeeds in forcing a long reorganization with a fork, he will be unable to include such transactions, making the fork obviously fake. This is a last line of defense, TAPOS is a great system to prevent long reorganizations but not a very good system to prevent short term double spending."