What's the motivation for this? Generally we've regarded the flags as rather esoteric troubleshooting stuff. The example output doesn't make it clear how unknown values would be handled.

The motivation is that it is more readable for an user which services the node provides, thus making it more convenient to use : no need to parse the flags himself (which needs to read the code to check what is the meaning of each flag).
Unknown values just won't pass the conditions and would not be returned, is it an issue ?

NACK, there could be some software that expects output of getnetworkinfo RPC as it is now. This will break compatibility. User-friendly services field could be added, but then as a new field, not replacing existing one.

Indeed.

Changed the behavior to add a new field instead of modifying the existent one. Edited the description.

I'm sorry, I don't see how "more readable" is actually helpful in and of itself. Why does anyone need to be reading these things?

Unknown values just won't pass the conditions and would not be returned, is it an issue ?

Yes, field is a lot more useful for unknown values-- e.g. reasoning about new or incompatible software-- than it is for known ones.

I'm sorry, I don't see how "more readable" is actually helpful in and of itself. Why does anyone need to be reading these things?

Actually, I made this after helping the guy asking about NODE_GETUTXO on the thread your responded to on bitcointalk. I thought that other node owners would wonder which services their node supports.
I understand that I may be wrong and this may just be useless, I close it for now.

For what it's worth, I would concept ACK something like this -- the times I use getpeerinfo tend to be times I'm debugging something, and having the service bits be more easy to decode would be helpful to me.

Concept ACK. I didn't know about this PR when I opened #16780. Don't override the existing field though. You could make the output more compact by presenting it as a string: NODE_NETWORK | NODE_BLOOM.

If people still find that too much visual clutter, especially in the already quite long output of getpeerinfo, you could add a debug param. If you go that route, then I suggest returning a dictionary with all possible flags and a true / false bool.

Reopening since @sdaftuar and @Sjors concept ACKed.
Rebased and modified, as proposed in #15511 (comment), the array to a string (this introduces some temporary variables but the output is much nicer) : since it only adds one line I think it doesnt worth a command argument addition.

Here is a truncated output of getpeerinfo:

"services": "000000000000040d",
"servicesnames": "NODE_NETWORK | NODE_BLOOM | NODE_WITNESS | NODE_NETWORK_LIMITED",
"relaytxes": true,

And one of getnetworkinfo:

"protocolversion": 70015,
"localservices": "0000000000000409",
"localservicesnames": "NODE_NETWORK | NODE_WITNESS | NODE_NETWORK_LIMITED",
"localrelay": true,

Reopened in a new PR (#16787) since I force pushed before clicking reopen....