If all the TxIns can be signed by one entity then there's little point in issuing an nLockTime transaction as they can issue arbitrary revisions until the time expires. They could get equivalent functionality by not issuing the transaction or not constructing it until it's needed.
Is this correct?
There are uses for locked transactions outside of contracts, for instance to set up recurring payments/subscriptions. If you don't want your wallet software to be constantly running/online, it might be helpful. I think it's unclear whether this will ever be done in practice.
Transactions involving nLockTime are used in forming various sorts of contracts
some of which involve creating and signing transactions spending incompletely signed transactions.
Which contracts are you thinking of? In the deposits example, the half signed transaction is not Tx1 but Tx2. Tx1 is created by the user to start the negotiation process and does not change after that.
I just noticed that the following paragraph I wrote about security-funding assurance contracts is indeed impossible to do:
The incentive transactions are broadcast before the assurance contract. They are considered to be orphan transactions because their referenced input (the contract) hasn’t been seen yet by the network, but pre-broadcasting them lets pledgers know what they are signing for and prevents the entrepreneur stealing the coins. Once the contract is broadcast, the orphan transactions become valid and can be claimed by miners once their block number is reached.
... for the reasons you state. But that is not really essential to the idea.
It's possible there are other bugs that page, ie things which are unimplementable, we won't know for sure until somebody actually does it. Eg, CHECKMULTISIG has a bug that requires a workaround, fortunately not a complicated one, but the Contracts page doesn't mention it because none of them have ever been tried in practice.