design rationale behind eth

I have a few general questions and questions about the design rationale behind the protocol, and why certain things are done the way they are:

1. In state/fast sync, it says that only data validity of blocks are verified, and `GetNodeData` is used to incrementally request Merkle tree nodes until the whole tree is synced. What exactly does "data validity" mean, and why does requesting the Merkle tree nodes have to do with it? Is this essentially having the nodes recreate the state trees?

2. In block propagation, nodes first propagate the full block via `NewBlock` to a small fraction of connected peers. This is only after the PoW validity is verified, not the bodies yet. The node then does body verification by executing txns, and finally then sends the `NewBlockHashes` message to all peers it didn't notify earlier. A few questions here: if only the PoW is verified, doesn't this mean the body may be invalid, and thus nodes are propagating invalid blocks and thus may be dropped as peers? If this is not an issue, why do we do this, instead of just verifying the entire block first before sending it? Is it because just verifying PoW is faster to propagate block while still offering some security, ie, we are making a security vs. speed tradeoff here?

3. Finally, in transaction exchange, it says when a new connection is made, transaction pools are synced. But it also says when new transactions appear in a client's pool, it propagates them to the rest of the network using `Transactions` and `NewPooledTxnHashes` messages. I don't have a full understanding of RLPx yet, but in general I'm confused as to what a connection is exactly. I understand RLPx is built on top of TCP, and don't TCP connections generate extra overhead and time? So if we want to propagate transactions across the network as fast as possible, and as I understand nodes have to make connections first, won't this introduce a lot of delay? And if these connections instead are long-lived, how long is that?