I find that it usually falls down to a 'supra'/'infra' (or meta/within) dichotomy:
- the 'supra-comments' are essentially used as "section headers", "block title / description", i.e. structural markers. It's thus logical to want them standing out, like titles in a text document or section borders in a spreadsheet.
- the 'infra-comments' are the "explicited subtext", "block/line anotation", i.e. substantive but secondary content (usually discussion about the code, which may also be externalized to a spec doc). These are naturally dimmed, because they sit beneath or outside the primary substance, the code (inline or aside, as in text documents and web pages, or even hidden behind a toggle).
In that regard, languages with two syntaxes for comments (eg. block "/* ... */" and end-of-line "// ...") may be formatted by editors respectively "standing out" and "dimmed", giving this two-level comment schema to the developer.
I personally think the 'supra-comment' / structural approach is detrimental to readability (longer, bloat, to me it's ASCII art however you want to spin it), and that problem should be solved by organizing code better (block order, files), choosing more self-explanatory names for everything, and having proper external documentation (however succint, it's not optional and can't be substituted by comments).