I think the above poster meant to imply that the 10ms delay would cover all market transactions, so if you put in an order now, then no one knows it till the next 10ms stop post.
Essentially its buffering all the data then releasing it at once, so it's not a truly continuous system anymore.
Trades occurring at other locations. Even if the other location are operating in discretized time, there's going to be variability in how fast different market participants can transmit information from one location to another. From Wolfram Alpha, Tokyo to NYC is 36ms at speed of light in vacuum and 51ms at speed of light in fiber, so someone with a faster network could be multiple discretized ticks ahead.
Stuff that happens in the real world. The stuff that all security prices are eventually based on. It's not a closed system you know?
For example, infrequent important events will result in a race for people to submit at the last microsecond, but because they're infrequent 99% of the time the 10ms buffering will effectively change the behaviour of market participants.
You can design the rules to optimize for one thing or another, continuous world notwithstanding. I'm suggesting a way to optimize for something more useful.
Are you perhaps confusing exchange in this case with a broker?
The window does nothing to remove the need for speed.
The world is a continuous system. No matter how hard you try you can't force it to be discrete.
(There are other problems in your proposed scenario to having to do with mismatched buy vs sell volume, but we'll ignore those for now.)