You mean if kinds were strings instead of numbers? Yeah, maybe, but essentially it would be the same thing (just from the name you can't get all the context regardless, like the schema, the ecosystem around it, the expected UXetc) and even if what you cite is a minor advantage there are also minor disadvantages (more bytes used, slower to parse, people still have to check some registry to see if they're typing the correct strings, names don't really correspond to anything so one would still have to check guides, names can actually give people the illusion that they understood or can be deceiving etc).
Discussion
Yeah, good points. Although you have MIME to lean on. At least that's how nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z and nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku propose it in their spec.
In any case, I'm all for moving the specs away from a central repo and into wikis. That then can be grouped in an index that can be referenced in actual App Releases.
We have m and M tags, and we use them. But I see them as explanatory and especially useful for more specialized kinds, like 30040s, so that people can understand what they are seeing in the wild. They're also useful labels for events, in search results.
I don't see the value in only having them, tho. I like kinds. Precisely because they are more ambiguous and don't feign exactness.
I don't really get the point of NIPs because I just search the repo for a kind number.