Additionally you can use iterated hashing: take the block hash b and hash it n times as in H(H(H(H(b)))) etc.

Since hashing is a serial operation, and each hash is a random mapping of input to output, with enough iterations (hundreds of billions) you make it completely infeasible for the miner to even know what the result was by the time they have to make the block public.

Zcash actually did this for their second trusted setup; IIRC the delay was set to be about a week's worth of computation. It's a much better scheme for many use-cases than anything else I've seen in this conversation. The main downside is exactly when which participate actually finds out what the final result is isn't well defined. But for cases where you can commit to the result in advance that's fine.

What Zcash did and Solana plans to use is a VDF without succinct verification. Unfortunately, I cannot verify it on a smart contract though, which brings me back to RANDAO + VDF for onchain verifiable randomness.

While you are right for most applications, it would not work for gambling or block selection in the case of proof of stake. Let say I'm flipping a coin (based on the last bit of the block hash) with you. You already locked the funds on the contract, waiting for me to commit to. I can wait until I'm the block proposer to push a block where I'm included. Even if we defined ahead of time how many rounds of hashing, I still have access to that information ahead of time and can decide to participate in the bet. Therefore, it is not secure randomness. (I won't get into commit and wait which could solve it but they are a pain in any case)

No need for commit reveal, just do a relative offset for picking the rng. So after you place a bet, 6 blocks later is the block that decides if you succeed or fail.

You can use simple techniques like this to make most use cases secure.