Under your proposal, maximum trade frequency would decrease from roughly (1 / second) to (1 / 10 minutes), a factor of 600.
Hence why you make a faster block time, say 12s. I'm actually in the process of discussing the safety of our own algorithms for this with some academics at Cornell right now; will let you know the results if you are interested. I think something like 5 blocks for a commit+reveal phase can get you down to a 90s average confirmation time.
The huge costs and risks of a faster interblock time are hardly worth this tiny issue of front-running resistance... Why you would even want more block headers at all is beyond me.
Wouldn't it be possible for front-runners to hash all {market , share} combinations, which would prevent the hash from really hiding anything? You could add salt, but that would cost more blockchain-space
Sure, but that would cost a large fee. The fee can be made to be proportional to the size of the trade if desired, although at some privacy cost (you would need to supply at least a rough idea of the size of the trade at commit time to make the fee enforceable). If you don't like that then you can have a two-level fee: a fee for not revealing during the reveal period, and a much higher fee for never revealing. This lets you enforce the smaller fee at reveal time and not subject users to too much risk since they only need to pay the larger fee if they are malfeasant.
I am referring to individuals building a big spreadsheet of { hash(Market A, Buy 1 share), hash(Market A, Buy 2 shares), ..., hash(Market B, Buy 1 share), ..., ... }. So that they know what a trade is as soon as it happens, and can front-run as normal.
That would not cost a fee as the blockchain would never know about it at all.
( In fact, if the front-runner just wanted to front-run a victim, they could just submit the same hash and then spend 9 blocks trying to figure out what it was. Do you plan to force weird trades like {Market A, Buy 1.00000008465 shares}? )