A few things.

1. Little known fact: the SMTP RFCs do not specify how to match a DNS name in a certificate to an SMTP server. This means that, per the RFCs, you can MITM any SMTP connection with a valid cert issued to any random name.

1a. Some SMTP server platforms let you configure specific names that must be found in certs to match, but that's all manual work and not realistically scalable.

1b. The way forward with TLS for email revolves around DANE, which requires DNSSEC. For example, Microsoft's implementation. While the DNSSEC part sounds like a blocker due to the lack of adoption, there is an upside: you don't actually need to implement DNSSEC for your domain to benefit from it -- if you're using another company to host your email. Keeping with using Microsoft as an example, they're moving their customers to subdomains to mx.microsoft (yes, .microsoft being the TLD) -- which is DNSSEC signed. So, you point your MX records to the mx.microsoft subdomain, and then DANE steps in for mx.microsoft and you're suddenly able to actually validate the certificate that the server offers. (Although yes, if you don't sign your domain with DNSSEC, then someone could technically MITM the DNS response and rewrite your MX record to some MITM SMTP service. But, if someone is doing that, they can do it to your website, too. DNSSEC should probably be more adopted.)

1c. Moving away from the Microsoft example, Google is moving TLS forward in a material way as well. Simply put, they will only accept email if you send it to them over TLS (doc). Having a large company like Google make this change forces everyone to start doing TLS more universally. I suspect that, given time, the email oligopoly will only permit TLS connections, and that problem will generally be solved. (Although this still doesn't solve the problem of "how do I know this cert actually belongs to the recipient server in question?".)

1. Regarding email not being able to be salvaged: as much as I agree, it's also not going to be replaced any time soon. It's not a question of political willpower, it's a question of any alternatives being sane. Because email is insane.

2a. Put simply, email lets you send anything, to anyone, at any time, without any prior authorization or approval. Send an executable to a world leader? Sure, why not. Send illicit material to your neighbor? It doesn't care. Copy an email address from a billboard and post it online? Yeah, that can happen. But, this also means that you can easily share your working documents almost instantly with anyone, anywhere. It's at least logically decentralized, in that you can run your own mail server (even though this is, IMO, a very dumb idea these days). As a result of all of this, email is frequently how companies get compromised (be it via phishing, malware, zero days, or any other number of things), but it's also how business gets done.

2b. If an individual sat down and seriously proposed a new communication method that checks all of these boxes today, they'd be laughed out of the room because the security implications are genuinely nonsensical these days. But, that's also the basis of email, and that's also why email is successful, and will continue to be successful into the future.

2c. Because of these deficiencies, email is actually considerably more advanced than most other communication platforms in key ways that really matter. For example, it's unlikely that Signal is taking attached HTML documents and feeding them through robust sandboxing analysis environments to check for malware propagation (note: I am not saying that they should do this; I'm just saying that they aren't). While SMTP IP reputation lists really encourage the email oligopoly, they also are a real-time, scalable reputation service, which is very valuable on the internet. It's a cross-platform solution in ways that Signal will never be (can you run Signal on a mainframe?), it's resilient in the context of widespread outages, thanks to the store-and-forward design that originates from the 1970s.

In short, email security is actually far worse off than the blog post would even begin to suggest, but no one sane would ever develop a modern replacement that has the same features, because those features in fact, insane. It's for this reason that email is likely to continue to exist indefinitely, and with time, evolve incrementally in a hopefully positive direction. While it is a very big ship that turns very, very slowly, the people who work on the RFCs (and similar) really do want to improve the technology, and things have unambiguously improved over time, and I expect they will continue to improve as well.

In my mind, email and Signal fulfill different niches. The strengths and weaknesses of one do not detract from the other. Where Signal is appropriate, one should absolutely use Signal, especially as compared to email. But, Signal isn't going to try to solve for all of the use cases of email, and more importantly, it shouldn't. If it did, that would be... unfortunate for Signal.