[Illustration by Matthäus Wander (Wikimedia)]
The block header is an 80-byte data structure that has two elements relevant for this question. Firstly, the header commits to the previous block per the previous block's hash. These links form a chain ensuring that there can only be one block at each height and forcing a potential attacker to commit to a specific point at which their chaintip forks off from the best chain. Secondly, the header includes the merkle root of the transaction list. This data structure is not "space-consuming". None of the intermediate hashes are ever stored or transmitted. Nodes can quickly regenerate the tree from the list of transactions to verify that they result in the correct merkle root and vice versa, the merkle root is a sufficient commitment to prove the existence of a transaction per a merkle branch.
While you note that the merkle tree allows for efficient proofs (which I'm sure users running thin clients on mobile devices appreciate), it also provides a structure to prove the presence of transactions in the blockchain in the first place! Without such a commitment structure, you might not have any proof that a transaction was included in the block, or perhaps needed to transfer the whole block every time to convince peers that a transaction exists.
The block header is covered by the proof-of-work—its eighty bytes must hash to a value that is less than the target (i.e. pass the difficulty requirement). Even if an SPV node only has the headers, it can easily verify that the block headers a) form a chain, and b) pass the difficulty requirement—by performing a single SHA-256d hash. On the other hand, producing a block header that passes the difficulty requirement currently requires about 130.5×1021 hashes. So, the argument is a) a well-connected SPV client with multiple full node peers should eventually hear about the best chain, and b) it would be extremely expensive to produce a fake header that isn't trivially exposed.
A full node cannot provide an outright fake chain, because if any byte in the header were changed, the header's hash would no longer fulfill the difficulty requirement. Since it takes an immense amount of work to create a valid block header, it's impractical for any node to provide a "fake header chain"—the receiver just has to check that the new block ties to the predecessors and do a single hash to verify that the header doesn't pass the difficulty requirement. Giving unconnected blocks won't work because the thin client can merely go back and check whether they connect to the Genesis block. So, "to fake a chain" the attacker actually has to put in the work to find headers that passes this simplest scrutiny. This is generally too expensive unless the attacker can expect to make millions. But if millions are on the line, you'll probably be running a full node and do some additional due diligence anyway.
It follows that a node can only lie by omission to SPV client, by not telling it about the best chain or not telling it about transactions. That's why SPV clients connect to multiple nodes and ask each for their best header chain. Once the SPV client has all headers, the existence of transactions then can easily be shown via a merkle proofs. Or better yet, by more modern SPV clients download the headers and the compact client-side block filters for each block. The compact client-side block filters allow them to search whether a block contains anything of interest to them, and when they notice something relevant, they'll just get that one block and parse it themselves.
So, SPV clients are susceptible to not having all information. They could also fall for an invalid block with a header that passes the difficulty requirement, since they don't check the whole block, but such a block would be expensive to fake.
