I don't quite get how "oracle" example is secure. This part:
The signature uses the SIGHASH_NONE flag, thus the recipient can be anyone (the oracle does not care). If the man dies, the son can claim the funds by taking this transaction, adding an output to one of his own addresses, and then broadcasting it.
What prevents malicious party from crafting similar transaction with his output?
E.g. it monitors broadcast transactions and when he sees son's transaction involving oracle sig it will copy it and replace output with his own and broadcast it too. Then it is a race condition. As you said, SIGHASH_NONE means that output is not signed so this copycat transaction is possible, right?
Or oracle itself can construct this transaction itself and just wait for son's input to be broadcast.
BTW I have an idea of how to implement escrow/oracle with somewhat different properties: to make a contract transaction you need to obtain a token (hash) from escrow/oracle service, but service does not need to work with each individual transaction. It is based on hashes, security is derived from complexity of first preimage attack.
Idea is simple: oracle generate an unique random number R associated with event E and announces its hash: hash256(R). Interested parties incorporate hash256(R) in scripts of their transaction. Then if event E happens oracle announces original random number R and it will unlock spending scripts.
In a simplest case:
scriptPubKey: HASH256 <hash256(R)> EQUALVERIFY DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
scriptSig: <sig> <pubKey> <R>
Use case can be similar to a legacy case, but oracle is required to associate an unique number R with event of death of "John Smith" before transaction is made.
It can also be used for making bets on public events, trading binary options etc.
For example, person A agrees to pay 100 BTC to person B in case exchange rate on a certain exchange is higher than 17.5 on a certain date.
An exchange itself or a third-party service will create a an unique random number RL_x_y for each event EL_x_y which means that exchange rate will be lower than x on date y, and numbers RH_x_y for each event EH_x_y which means that exchange rate is higher than x on date y.
Now A should obtain hash256(RH_x_y) and hash256(RL_x_y) from service and create a transaction for 100 BTC with scriptPubKey like this:
IF HASH256 <hash256(RH_x_y)> EQUALVERIFY DUP HASH 160 <pubKeyBHash> EQUALVERIFY CHECKSIG
ELSE HASH256 <hash256(RL_x_y)> EQUALVERIFY DUP HASH 160 <pubKeyAHash> EQUALVERIFY CHECKSIG
Now if exchange rate is higher service will publish RH_x_y and then B will create txn with scriptSig:
<sig> <pubKeyB> <RH_x_y> 1
otherwise A will create similar txn which unlocks money to him.
An advantage comparing to signature-based escrows is that service only needs to publish a hash and a random number, but it does not need to process each transaction individually. Also, hash and number are rather small so it is easy to just copy them into GUI form field, so there is no need for software integration between contract-making GUI and service: this service can be a simple static web page.