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.