The engineers at Google were well aware that ASN.1 existed. I can assure
you of that, because I was one of them.

The protobuf FAQ has a very polite take on the matter:

   https://developers.google.com/protocol-buffers/docs/faq

This email thread gives more enlightenment:

   https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4

Anyone who has actually had to work with both ASN.1 and protocol buffers
will be able to explain why ASN.1 should not be chosen for any modern
formats. A lot of it boils down to simplicty and quality of
implementations, especially open source implementations.

With respect to the specific concerns Richard raises:

Performance doesn't feel that relevant when you think that:
>

Performance wasn't a concern.


> 2. One would be cramming this data into a binary format just so you can
> then attach it to a no-so-binary format such as HTTP.
>

HTTP transmits files as binary on the wire. So it's binary-clean and,
moreover, HTTP/2 aka SPDY is fully binary and doesn't use text anywhere
except the gzip dictionary.


> 2. There are tons of great open source libraries and API for parsing /
> manipulating / generating.
>

Luckily, this is also true of protocol buffers. Language support is pretty
good these days.


> 4. The standards are much easier to read and write. They don't need to
> contain code like BIP-0070 currently does and they can contain examples,
> which BIP70 does not.
>

BIP 70 doesn't contain any code, as far as I know. The protobuf schema
might look like code, but it's not - it's just a description of what fields
a message can contain and their types. This is very relevant for a
specification!

JSON in particular is pretty awful and I don't like it much. It suffers
complexities with things as basic as encoding numbers and strings. It's
very much unsuited to applications where correctness matters and where
you're dealing with binary structures.