It certainly makes sense to include relations between requirements and source code in the requirements traceability matrix. If requirements change, we've a direct view on the impact on source level. But can this be managed and maintained, even with a tool? Is it wortwhile to put a huge effort in maintaining relations between requirements and the source code? Isn't it sufficient to define these relations at the level of design elements and user acceptance test cases? In this case, we've a means to verify that each requirement is covered by design and test. I believe this strongly reduces the risk of uncovered requirements in the final delivery, which is one of the main purposes of requirements traceability.
The answer is, you do whatever is necessary to meet your business goals and objectives. It depends upon the criticality of the product or service you are delivering. If your product is highly complex and someone could lose their life if there was a missed requirement, then it is necessary to put a huge amount of effort into requirements traceability. Just consider the Space Shuttle program, the amount of requirements etc. The Space Shuttle software is as close to zero defects as you will ever find. And at the other end of the spectrum, you would be justified limiting the amount of effort for traceability.