LibreSSL languishes on Linux

I don't think it's correct to say that "number of extension need to be kept in check". The concern was around the core primitives, you probably don't need eight different block ciphers whose main distinguishing feature is which major world power sponsored their development, you don't need to keep obsolete and arguably unsafe key exchange methods available just because it suits a few implementers, and so on. But the extensions have, if anything, multiplied.

The nice thing is that (within their assumptions†) the correctness proofs don't care about extensions. If you use certificate compression (forthcoming TLS 1.3 extension) or flags (likewise) or even Encrypted Client Hello (far more radical, but ultimately expressed as an extension) you keep all the behaviours that were proved, because the proof doesn't care.

† And there's a crack. For example the only known TLS 1.3 attack "Selfie" depends on an unstated assumption of the proof. The proof assumes PSKs are singular, if Alice and Bob each run both a TLS client and a server secured just by PSK, they actually need _two_ PSKs, the Alice->Bob key and the Bob->Alice key. But this assumption isn't spelled out. Lacking such explicit warning you might assume one Alice+Bob key will get the job done, then Mallory redirects Alice's call to Bob back to Alice, Alice's client assumes she's talking to Bob and mistakes her own answers for Bob's. Does that blow up your security? Alas RFC 8446 as written does not warn you that this would happen and what countermeasures you should use to avoid it.

Then you are in agreement with the poster you quoted. They just used a different way of stating it.

Firstly this doesn't seem responsive to the question. I asked for an example, and what I see here is an excuse. I think this is because you do not have such an example, that in fact "most protocols" do not deliver what you claimed after all.

Secondly, RFC 8446 is designed to work fine without certificates. You get a complete working system, including forward secrecy. However in this model you'll need to agree Pre Shared Keys with every single server you want to talk to (and they should agree separate keys with each of their clients). This might be nice for a system that connects speakers in each room of your home over WiFi to a central music playing device for example, but it's not viable for visiting arbitrary web sites.

The need for a PKI (and thus Certificates) happens when you'd like (as we do) to securely authenticate any system connected to the Internet. And this isn't out of some weird fetish for as you say 1960s technology, we simply do not know any alternatives that actually work. The usual claims are either that TOFU is "good enough" (good enough that you'll get exploited and never know it, perhaps) or that the Web of Trust works at scale (it does not).

Exactly. In those days, everybody was well-behaving on the Internet. People logged in to remote systems using telnet and rlogin, ran commands on remote systems using rsh, and used "xhost +" to interact graphically with programs running on remote systems.

After one-too-many pranks, the latter was quickly replaced by custom scripts calling xauth and copying over magic cookies to remote systems.
As network sniffing increased, people started to worry about security. Fortunately ssh (incl. -X) arrived, making most of the above issues moot.
But the WWW was still (mostly) limited to plain HTTP...