Forget about the Merkle tree. Assume that instead, the block header would just contain a hash of the concatenation of all transactions.
A lightweight node could then download all headers, verify their proof of work, and make the assumption it has seen the longest chain. It is now convinced it has seen the chain the network accept. This is different from a full node, which does not assume a chain is accepted until it has seen all block data and verified every single transaction.
Now the lightweight client decides to ask peers for the actual block data. When it receives a blocks' transactions, it knows they actually match what the block header committed to, as it can recompute the hash, and compare it to the value in the header.
But what if the lightweight node is not interested in all transactions? BIP37 introduces the concept Bloom filtered blocks, where a lightweight node can reveal what keys/transactions/addresses it is interested in, and the full node it is downloading from will only give the transactions that match the filter.
Unfortunately, if the lightweight node does not download all transactions, there is no way to know whether they match the hash in the header, and as such, the full node could lie, and include transactions that are not actually present in the chain.
Enter the Merkle tree.
Instead of just storing a hash, we store the root of a Merkle tree. The full node can now for each matched transaction include the hash values that transaction's hash is combined with, to prove that the transaction is in fact included in the tree, despite the fact that the lightweight node only knows the root.