Makes sense to me.  Communicating via comments that groff ignores these lines is important to anyone looking at the files who might otherwise conclude this is a useful thing to do.  But the lines don't actually have any effect, so whether they're specifically commented out (as opposed to merely being commented upon) doesn't seem to matter much.

As bug #57506 notes, the font files in devps live in a gray area between original source files and generated files.  I don't know how much of their content comes from afmtodit and how much (if any) is manually edited after the fact.

As bug #58718 observes, groff does not allow kernpairs in its font files with a space as the first element.

Despite this, several kernpair entries in a handful of font files (specifically font/devps/{[HN]*,PR}) have "u0020" as the first element.  True to Werner's assertion, these lines seem to have no effect.

$ cat kerntest
.de sample
A Very Yellow Tortoise Always Wins.
..
.ps 24
.vs 24
.nf
.sp
.fam N
.sample
.fam New
.sample
.fam Newest
.sample
$ mkdir /tmp/devps
$ grep -v ^u0020 /usr/share/groff/current/font/devps/NR > /tmp/devps/NewR
$ grep -v '^[VTY] ' /usr/share/groff/current/font/devps/NR > /tmp/devps/NewestR
$ groff -F/tmp kerntest > kerntest.ps

The first two lines of the resulting PostScript file look identical, despite the lines using font files that specify different kerning rules around spaces.  The third output line definitely shows by contrast the absence of kerning after some of the capital letters.

Groff shouldn't ship font files with lines that don't do the advertised job.  Ideally, bug #58718 would be fixed so that these lines do work.  But if a fix for that bug is not ready by the time of the next release, the nonfunctional lines in the font files should be removed.