To me that is a specious argument. It's like asking why Python was invented when Cobol could suffice.
The dozens of ASN.1 specs are absolutely hideous and entrenched in obsolete telecom jargon. If the sole goal Protobuf was to avoid having Google engineers be required to refer to the dozens of ASN.1 specs when disagreements or confusions arose, then it would have been 100% worth it for just that reason.
First, let me confess that I don't have enough experience with ASN.1 or
Protobufs to have an informed opinion.
The supporting argument for the "because it's there" hypothesis
for why people reinvent things (in IT) is that they do it so often.
Even if all the newer message/serialization systems are better than ASN.1, they're not all better than each other, eh? Why so many? Same goes for chat systems, programming languages, etc.
There has been a lot more new stuff in the world of programming languages, even recently, than there has been in the world of data schemata and encoding rules.
That said, most of the innovation in programming language theory has been around Haskell and related languages, and it has not justified languages like Golang or Python. DSLs in general are justified regardless of whether they are innovative in terms of programming language theory.
The ASN.1 specs are beautiful. They are beautifully written, better than anything the IETF produces because the ITU-T is an expensive standards development organization that can afford to have people who only do this sort of thing.
The ASN.1 specs are very readable. Much easier to read than many important RFCs.
The dozens of ASN.1 specs are absolutely hideous and entrenched in obsolete telecom jargon. If the sole goal Protobuf was to avoid having Google engineers be required to refer to the dozens of ASN.1 specs when disagreements or confusions arose, then it would have been 100% worth it for just that reason.