The authors make a bold statement:
If we've learned 3 important things about cryptography design in the last 20 years, at least 2 of them are that negotiation and compatibility are evil. The flaws in cryptosystems tend to appear in the joinery, not the lumber, and expansive crypto compatibility increases the amount of joinery. Modern protocols like TLS 1.3 are jettisoning backwards compatibility with things like RSA, not adding it. New systems support just a single suite of primitives, and a simple version number. If one of those primitives fails, you bump the version and chuck the old protocol all at once.
I understand the criticism about the many algorithms that OpenPGP supports and that it may be too long and too difficult to implement all of them smoothly and correctly. It is a frequent criticism. As a non-expert user, I myself feel unconfortable when I have to choose create a key (I use the default, knowing that it might not be the best option).
However, I must admit I don't see what is the issue with negociation (and compatibility). A standard is the product of a negociation, and if people use it, that is because it offers them something, probably a tool box that you can adopt and adapt. ProtonMail decided to use ECC by default (which is supported by most of the implementation) while GnuPG use RSA 2048 as default. But if she use up-to-date application, Alice can send emails to Bob without worrying about key types because of standardization. With Signal, your interlocutor need to use Signal as well.
By the way, the comparison with TLS 1.3 seems quite vague to me. It was negociated during months at the IETF (the same standard body as OpenPGP) and many servers do not support it so that we still need TLS 1.2 and even TLS 1.1 in some cases. It might not be the greatest comparison...
There are two interesting quotes regarding the question. First, at the very beginning of the article, the author affirm:
"PGP" can mean a bunch of things, from the OpenPGP standard to its
reference implementation in GnuPG. We use the term "PGP" to cover all of
these things.
Second, in the section "Incoherent Identity", they specify what they mean:
PGP is an application. It's a set of integrations with other applications. It's a le format. It's also a social network, and a subculture
PGP pushes notion of a cryptographic identity. You generate a key, save it in your keyring, print its ngerprint on your business card, and publish it to a keyserver. You sign other people's keys. They in turn may or may not rely on your signatures to verify other keys. Some people go out of their way to meet other PGP users in person to exchange keys and more securely attach themselves to this "web of trust". Other people organize "key signing parties". The image you're conjuring in your head of that accurately explains how hard it is to PGP's devotees to switch to newer stuff.
None of this identity goop works. Not the key signing web of trust, not the keyservers, not the parties. Ordinary people will trust anything that looks like a PGP key no matter where it came from – how could they not, when even an expert would have a hard time articulating how to evaluate a key? Experts don't trust keys they haven't exchanged personally. Everyone else relies on centralized authorities to distribute keys. PGP's key distribution mechanisms are theater.
Let's analyze the issue. Ordinary, it is true that we speak indistinguishably about "PGP" as a standard and an application. But we shouldn't. Pretty Good Privacy (PGP) is an application designed in the late 80s and early 90s by Phil Zimmermann, and published in 1991. OpenPGP is an open standard (RFC4880). GnuPG is one of several implementations of OpenPGP. Okay... this lack of precision of ordinary language may matter for some people.
But this quote addresses a more fondamental issue: "PGP" is linked to a whole "crypto-imaginary" including web of trust, key-signing parties and cryptoparties. It might be that for some people (is there such things as a "community"?), "PGP" has a much broader meaning than just a way to encrypt things. This is a methodological challenge of this research: understanding the various "scripts" of a blurred object (or should I say "actant"?), understanding the connections between all these people and objects, understanding the different and competing definition of "PGP".
The aim of this article is very clear right from the start: to convince the readers not to use PGP. To do so, the authors enumerate a long list of criticisms that are not new. Reading this offers a argumentative recap of established criticisms of PGP. In this article, PGP refers both to the IETF standard and its implementations (although the authors only mention GnuPG). I just quote some points the authors address, without making a stand (not my role):
Some of these points are really not new. Long-term secrets and forward secrecy were for instance addressed in 2004 in a publication that present OTR as a counterpoint of PGP. In addition, Matthew Green and Moxie Marlinspike also mentionned similar criticisms about forward secrecy, and most importantly complexity in respectively 2013 and 2015. Common controversies about one of theses issues (especially about difficulties to correctly use GnuPG and to choose the right algorithms among different communities like the GnuPG-users mailing list).