The usefulness of JSON is that while both systems still need to agree on a custom protocol, it gives you an implementation for half of that custom protocol - ubiquitous libraries to parse and generate the format, so the application needs only to handle the semantics of a particular field. If they made a custom format from scratch, both apps would need to reinvent the wheel and write a bunch of boilerplate code for serialization, deserialization and handling format errors.
This does not apply for URNs - the "custom protocol" replacing URNs is simply transferring a string, so choosing URNs doesn't save most apps anything.
The other aspect is that I (and looking at the other comments, probably most people) don't really identify with your use case i.e. "a standard way to refer to "an ID taken from an existing public registry"". The common use case for handling IDs from an existing registry is in systems where the requirements specify a particular existing registry, not an arbitrary one; and any URN which specifies some other registry should be rejected as invalid, so including that in the data is just useless overhead.
In general, I consider that is useful to have a reference to a specific registry if and only if I have some special integration with that registry. I.e. it's useful to denote that this is a registration number from the Danish company registry iff I do something specific with the Danish company registry (e.g. fetching whether that registration is valid and the company has not been liquidated). And in that case, I don't really need a universal format to represent arbitrary numbers, I need an 'enum' showing that this is one of the acceptable (closed!) list of number types the system can understand, or possibly even split them in separate fields in JSON/XML/whatever.
On the other hand, if try to I imagine some use cases where really there is a need for processing IDs from an open set of many registries (which exist but IMHO are quite rare) then in those cases the interpretation of these IDs is generally not done by the computer system, they are transferred and stored as-is, and perhaps later printed shown to a human. In this case, having a machine-readable URN is not an advantage, as the computer system doesn't care which registry is being used (so it doesn't need to tell that its looking at an ID in a registry, much less which registry) and potential human consumers of the data (end users like customers, accountants, etc - from whom a URN is definitely not 'self-documentary') would not be able to write or decode URNs, they would not recognize that a URN represents an ID in a registry or tell which registry is used, they would need a different, human-readable format for that.