But as I said earlier in the thread, there is a tradeoff here between crypto strength and code complexity, and "the strength of the crypto is all that matters" is NOT security first.
I should be more explicit about code complexity:
The big picture is "segwitness will help scale in the very short term."
So the spec gives two ways of stuffing the segwitness hash into the scriptPubKey -- one way that uses a 32-bit hash, but if used would actually make scalability a bit worse as coins moved into segwitness-locked transactions (DUP HASH160 EQUALVERIFY pay-to-script-hash scriptpubkeys are just 24 bytes).
And another way that add just one byte to the scriptpubkey.
THAT is the code complexity I'm talking about. Better to always move the script into the witness data, in my opinion, on the keep the design as simple as possible principle.
It could be a 32-byte hash... but then the short-term scalability goal is compromised.
Maybe I'm being dense, but I still think it is a no-brainer....