> All this is supposed to limit address that the outputs can be spent to by using a script, but how?

What OP_CTV actually does is limit the *transactions* that can be sent to only ones with that specific set of attributes. The set of attributes chosen is intended to ensure that there exists only a single transaction that can fulfill the template. The "outputs hash" in the list is what limits the addresses the transaction sends to.

OP_CTV is basically just one step beyond a pre-signed transaction. With presigned transactions, you require some countersigner to sign a set of transactions that become the only possible transactions you can use to utilize one or more outputs. With OP_CTV, you get rid of the need for some countersigner and can ensure that a set of transactions are the only ways to spend particular outputs.

By contrast, OP_CD is more flexible and there is flexibility allowed in the transactions that can spend outputs locked by a script that uses OP_CD.

> The BIP (119) says P2SH is unsuitable for this,

What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.

> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?

I don't think I quite understand your question. Would you mind elaborating?

> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.

Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?