Here's the problem: the replay attack. The way the fork code was designed, any transaction sent on one side of the fork will only be sent to peers on that side (p2p network split). But, nothing invalidates the TX on the other chain; so the transaction body itself will be equally valid on the side. So, if you capture the transaction from one side, and just route it to a node on the other, it will proceed on both sides. This creates lots of potential attack vectors – replay attacks going both directions on the chains, and worse, imagine the chaos if we somehow have to revert and go back to the original chain post-fork when it was devastated by replay attacks while no one was looking (everything always goes according to plan and software never has bugs...right?)

Old-To-New Chain Replay Attack: I hear people not taking this seriously because, why would replay to the OLD chain what happened on the NEW chain, it has no value. That's a minor issue. What about if the OLD chain keeps working, and you replay OLD chain TXs on the NEW chain, and are thus able to steal NEW chain valuable ETH? That's the major concern. If two chains operate together, I would expect to see TX replays on both sides, and it'll be chaos.