I disagree with the previous answer.
It appears that the respondent does not develop for WordPress:
"Think of unit testing. In that context you are likely to call the function by itself"
This, obviously, is not feasible for the overwhelming majority of WP code.
However, the "move the call" statement is, although infrequent because almost all hooks are designed to perform a very specific act, a valid concern. What is more typical is that an existing filter will end up being used by multiple hook IDs, as some of the IDs are dynamically generated, but statically referenced. The case where it is dynamic on both sides is beyond any kind of documentation parser's abilities.
I think the correct solution is something that parses add_action and add_filter calls into references of some kind like maybe @hook_for (I am just getting into this phpdoc stuff, so bear with me). This may be in a docblock, "special comment", or even just some kind of helper in doxygen or the like (but manual access is also needed to cover edge cases).
What I want is for doxygen or phpdoc to gather these @hook_for references into caller/callee lists like they do for normal function references - but obviously in a separate part of the output. Knowing which hooks a plugin or theme uses, and being able to 1-click to the code would be an amazing thing to have.
Now that I have invented a new "@" tag, hopefully someone will come along and say "that already exists - use this". I've looked at @see and @link, but not in depth -- maybe they are the answer? But, for the best results, we still need them to be auto-generated by something in the pre-processor (the add_filter/add_action parser I propose).