Hey Viktor, I saw this is your first post here. I’m not very active myself, but still…welcome!
I can see your point that “merkleizing” the witness itself can bring flexibility in light client design. Now about the client which doesn’t verify the merkle hashes and only uses the witness data section (let’s call it an anti-merkle client): As you mention yourself this client suffers from worse security specially at the tip of the chain as it relies on consensus for security and consensus is hazy at the tip.
Aside from that I wanted to raise a potential edge case. And that is a crafted block that fully verifying client can execute correctly but an anti-merkle client fails to execute (correctly). One example I could think of involves exclusion proofs. Depending on the witness format details (e.g. in turboproofs), it might be impossible for an anti-merkle client to distinguish between a leaf not present in the witness and a leaf not present in the state trie. Of course in that case it could request the merkle hashes to resolve this.
Btw since this client design needs to download and verify the header chain it might benefit from chain history proofs like other light clients to reduce network bandwidth further.