There are a lot of post that talk about this. I highly recommend you search and read some of the older discussions. Regardless, I will reply here with some top of my mind recommendations.
1. How effectively we can handle the duplicates in CMDB? What are the best considerations for reconciliation job to avoid duplicates in Asset dataset or golden dataset?
Considering you are on CMDB 8.1.02 the CMDB Engine itself will not allow two CIs in the same dataset (for this purpose the ADDM dataset) to have the same ReconID. That means that even if the new Computer is identified by RE to be the same computer as the old one (the one that is now MAD) the CMDB Engine will not let RE to assign it the same ReconID. Instead this new computer will remain unidentified until the old computer is purged. This in fact means you need to run regular purges in ADDM data so that those MarkAsDeleted sent by ADDM are effectively deleted regularly for the new CIs to come in.
Here you have two options in regard to ASSET. You could purge ASSET as well, deleting the OLD CI also, or you could avoid purging ASSET, letting the old CI there and the NEW CI will now merge to the new one, "refreshing" it's attributes to reflect the new values.
2. How to avoid the issues like ADDM not setting MAD status of same old node in CMDB when ADDM discovers new node with major changes?
That I do not know for sure. I'm not an ADDM expert, so maybe someone else can answer. I do not remember seeing this issue, and probably if there was such issue, it was resolved by the 10th release of ADDM, so I would not worry about it.
3. Do we have any matrix which signifies the fields upon which ADDM creates new nodes in case any major changes on these fields?
My understanding is that this is a custom setting. There are some default defined in the ADDM engine, but you could change these to reflect some specific behavior in your environment. Maybe someone from Discovery / ADDM can tell us more.