I see your confusion, from that perspective, you're absolutely right. But the usefulness of Merkle trees isn't in its 'fast lookup', it is rather in its bandwidth efficient way to prove that something remained unaltered.
With Merkle tree you just need a path from leaf to the root - so O(log n) hashes required.
It still seems that the problem can be solved by including a hash of the previous record as part of each new record. Then to verify the validity of any given record, you just fetch that record, its predecessor and its successor. If the record's hash cannot be computed using the predecessor's hash plus the hash of the current record's transactions (in a way that it's consistent with the successor's hash), then you know the current record is invalid.
That is not possible when you are querying many full nodes for current node, without telling them what you are looking for. They cannot return different results based on your query. You can trust that one piece of information - newest block.
In order to verify validity of the record, you need the block containing that result and checking that it is in history of the current block. That requires fetching O(n) blocks. Keep in mind that you need to trust just the head - even if someone wanted to provide you fake history, they are not able to, as it is infeasible to create block matching specific hash.
But instead of having linear block chain (corresponding to list datatype) you can have a Merkle tree (corresponding to tree datatype), where it is possible to compute hash of each node having just its two children. You can anchor your knowledge in the hash of the root (e.g. by having all nodes provide you the same value). Than anyone can prove you in a trustless way, that the tree contains specific leaf: by providing way to verify the hash of all nodes on the path from the leaf to the root. That requires O(log n) data, compared to O(n) in linear blockchain.