In traceability matrix the links between requirements and tests can help answer:
- Which requirements is almost never tested, and which is tested extremely often?
- Will a change to a particular requirement cause revisions to a huge number of tests in the system?
In agile there are no requirements but stories, so traceability matrix does not exist in traditional sense. Well, stories describe requirements but when you complete story, you close it and then you close an iteration and forget about that story. It is done, accepted, and closed. So maybe this is a reason, why in software we used for planning and tracking of iteration and tests there is no such matrix.
Or maybe my guess is wrong. I'm curious whether you use kind of traceability matrix (linking stories/epics with tests)?
One place I would see it useful, is when you get additional budget/iteration to verify your epic better and you want to decide which stories require additional testing...