The cut and choose aspect is not requiring any details about bitcoin scripts. The idea is that one side commits to a large number of keypairs, the other side picks a random one and then the original side sends the privkeys to all keypairs except for the chosen one.
Probabilistically as long as the cost of the fee (which is required) must be more than the expected return. Current settings are 1000 keypairs and 1/777 as the fee, so there is about a 13% negative cashflow for anybody that tries to cheat on a large scale. Now whether preventing economically motivated attackers is enough or not, clearly it is a necessary problem to solve completely.
You have not explained to me what cut and choose solves, how it solves it, etc.. The quoted explanation is incomplete. I have no idea why cut and choose was even introduced as a replacement to TierNolan's original protocol which used a single hash.
I tried reading the original discussion where cut and choose was first introduced and it doesn't quickly register for me. I think because it was explained by example employing Bitcoin op codes which I don't understand and also perhaps there were some lapses in explanation due to the those in the discussion not writing down what was already clear to them in their minds (and I am not able to read minds). Perhaps if I tried harder I could reverse engineer what is being introduced, but in the interest of saving time, I wish one of you could explain it clearly.
I do understand the notion of an interactive probabilistic challenge function where the cheater can't cheat unless they can guess which challenge you will provide. The Compact Confidential Transactions uses this to prove in zero knowledge a number is contained within a much larger interval. This can when required be converted to non-interactive with the Fiat-Shamir transform. I just don't understand the application here.