Hey Daniel,
I also see value in helping users understand the gaps between an external analyser and SonarSource analysers. To be entirely honest, in my past as a SonarQube admin I also found these reports helpful (specifically with FXCop).
There are some interesting challenges with creating these reports – one is that SonarJava is not necessarily trying to be FindBugs, PMD, etc. SonarSource might disagree with a rule implementation, or find a different one that has more value. How does SonarSource provide a mapping then, if the issues raised on code could be different? I think it’s very real to imagine users who won’t think of SonarJava’s implementations as equivalent unless there is an exact match. 
Perhaps SonarSource decides a rule isn’t relevant or that implementation is too costly to have a real benefit (too much noise, too many false negatives, etc.) Maintaining comprehensive information about why we did/did not include a rule from another analyser is not necessarily a priority because… SonarQube is not meant to just be a substitute for other analysers.
Finally, as other analysers grow and change, and as SonarSource’s grow and change, it becomes non-trivial to keep these reports up to date.
These are not blockers to helping users transition to our code analysers from others (and in fact, we are only strengthening the ability to import rules from external analysers) but they are some of the challenges.
Colin