Should a vulnerability in a service that is present on the device, but not running and not used at all, be mentioned in the vulnerability report?

It depends on how your organization uses these kind of reports.

If the people responsible for planning and/or implementing security controls read these documents once and then never look at them again OR see them more as a guideline than actual rules on how to set up an environment, I can see that you might want to refrain from adding too much information into the report. Just because you want to make sure that the vulnerabilites that are acutally present are met with saftey measures.

On the other hand if these are "living" documents that set rules on how controls have to be planned and implemented AND the people who are responsible update these documents if the infrastructure changes at a certain point, you definitely want to include these vulnerabilites.

IMHO as someone who organizes information security in an institution this is the kind of culture you should push for.

If you are afraid that your document will become too cluttered, you can always work with its structure. Something that was done in an organization I worked with, was, that vulnerabilites like this or possible future vulnerabilities were added in an annex to the main document. If the infrastructure was changed in any way, admins could check the annex first, if any of the changes would bring in the vulnerabilities listed there.

One last point I would like to make: although YOU didn't enable those features, this doesn't mean an attacker won't do it after he/she got access to the router. So implementing security measures just in case can be reasonable. This might be something that should be evaluated in a risk analysis though.

To quote ISO/IEC 27005:

The presence of a vulnerability does not cause harm in itself, as there needs to be a threat present to exploit it. A vulnerability that has no corresponding threat may not require the implementation of a control, but should be recognized and monitored for changes.

As a customer of vulnerability reports, I would say yes, but it is certainly a waste of time to give it equal weight as other vulnerabilities. E.g., live, exploitable massive remote access holes or active malicious backdoors wouldn't get the same coverage as something like a DoS vulnerability or in this case a vulnerability in a disabled bit of software.

IMHO the report should have an executive summary, a technical findings, then go into the tedious detail.

Something like what you describe would be a one-liner in the technical findings and have some info in the tedious details section.

CVE-2016-6380 would however mean that you're not regularly patching the devices, or you have a very slow patch cycle. This might be an accepted risk on the customer's part, but it should be reviewed. It may be worth mentioning this in the executive summary. No CVE# stuff, execs don't care.

See further in NIST 800-115 7.3

...

While individual vulnerabilities need to be identified and resolved, identifying the root cause of vulnerabilities is key to improving the organization’s overall security posture because a root cause can often be traced to program-level weaknesses. Some common root causes include:

• Insufficient patch management, such as failing to apply patches in a timely fashion or failing to apply patches to all vulnerable systems

...

First of all you need to have a scope of what you are scanning for and what you are reporting on.

For example is the scope of the scanning to discover and report on all vulnerabilities including low risk vulnerabilities, or just high risk one, or maybe just critical vulnerabilities. This should have been defined before you even started the vulnerability scanning.

If it is a confirmed false positive then remove it from the report.

If it a service that is present but not used and it is a confirmed in scope vulnerability then include it in the report so the service can be removed from the target.