In current versions of Bitcoin Core, most transactions are only relayed once and all transaction are only validated once.

New blocks and transactions in Bitcoin are usually advertised to peers by use of inv (inventory) messages. Blocks are thereby identified with the hash of their header, while transactions are identified by a hash over the complete transaction (also called txid). The peer that receives the inv message will respond by requesting the block header, the full block, a compact block, a Merkle block, or the transaction data if they want it.

Transactions are only relayed twice on older implementations of Bitcoin Core that always request the full block when it is announced by a peer for the first time. Newer implementations use Compact Blocks which transfer only the block header, an encoding of the transactions and up to a handful of transactions that the sending node didn't have when it received the block itself. Nodes don't revalidate transactions that they already had in their mempool, as transactions get validated before a node adds them to their the mempool.

^{via Compact Blocks FAQ}

The full list of transactions must be stored in the blockchain to allow new peers to independently validate the entire transaction history of Bitcoin.

You mention in your comment that They can still put full transactions to the full blockchain. This is exactly what they are doing. The full blockchain is simply a collection of the blocks. Since the blocks contain the full transactions, the transactions are in the blockchain.

If the blocks contained only the transaction hashes, the raw transaction data would have to be stored and transmitted separately. This adds more overhead.

There have been proposals to allow nodes to broadcast a tx hash list and the block header, based on the assumption that most nodes will have most transactions in their mempool. They can then assemble the full block themselves before validate and saving it, requesting any missing transactions from the network.

I'm not sure if any such proposal was implemented, however.

Transaction should be verifiable (and may be verified) by each full node. If block only contained the transaction hashes, any node who has not been online during the transactions propagation, or simply has not received the transactions, would not be able to verify the correctness of the transactions referred in the block.

Furthermore, when new nodes join the network they request the whole blockchain from their peers, and verify that each block ever included in the blockchain is correct, which refers to the previous statement. (Actually there are certain checkpoints in the process, but lets keep it simple. You can refer to this question for further information about them.)

only include transaction hashes

Blocks must include transactions. It's the way how transactions are archived. Otherwise, over 100 GB of transactions had to be stored in mempool.

However, you're right. Each transaction is broadcast twice: Once when a user makes a transactions, once when a miner creates a block containing it. There have been various solutions to that: (The primary goal is: relay the least amount of transaction data (smaller than TXID!) to other nodes.)

• Xthin: Uses bloom filters

• Compact Blocks: Slightly better Xthin

• Graphene: Yet the best (without a properly tested implementation) way to relay new blocks, using both bloom filters and IBLTs.