Why does a thin node need to know if a transaction is present in specific block's merkle tree? I understand what a merkle root is and how merkle proofs work.
It's all about thin nodes checking whether a specific transaction ID is in a specific block. So, thin node says: I have a transaction ID - 12345 and I want to know if this transaction is present in  259,291th block.
Why would a thin node want to know information like this ?
Why would a thin node want to know information like this ?

They quite possibly don't care about exactly which block the transaction was included in, but they most certainly care about knowing the transaction was included in the blockchain at all. It just so happens that there is no easy way to prove the latter without proving which block it is included in.
To illustrate a more concrete interaction (as used in BIP37, but other protocols like Electrum's client-server protocol are similar). F = full node (the server), L = light client. This is obviously not an actual protocol dump, but conceptually it's close.

L: Hi F, I'm a light client and am interested in transactions involving addresses A, B, and C. [filteradd]
F: Okay. [nothing]
L: I have synchronized blocks up to block hash H. [getheaders]
F: Oh dear, you're behind, there is also block I and J. Here are their headers! [headers]
L: Those headers look great, and their proof of work is valid. So eh... does I contain any transactions I care about? [getdata with MSG_FILTERED_BLOCK]
F: Nope. [empty merkleblock]
L: Okay... what about block J [getdata with MSG_FILTERED_BLOCK]
F: Oh yes, here is transaction T that involves one of your addresses! [merkleblock]
L: That looks like a transaction that indeed pays me... but can you prove it's actually been included in the chain? You know, I don't trust you really and you could be giving me an invalid transaction, or one that spends money that has already moved in the chain. [nothing]
F: Fine, here is a Merkle path that proves T is in fact included in block J. [part of the earlier merkleblock message, actually].

So the point is that without the proof, F could be claiming that L got paid, while the transaction is invalid. Having it included in the chain makes that very expensive, assuming other nodes in the network actually enforce validity of transactions in the chain.
There is a caveat of course. There is no way that F can prove to L that block I didn't include any interesting transactions. The solution to that is either trusting the server, or trying multiple - neither is very satisfying.