Start by understanding this: end-to-end (e2e) security is not a crazy pipe dream. It can be accomplished today, using tools with graphical interfaces that are available on all mainstream platforms. Though we could surely use better, more convenient tools for providing it, there's no valid argument that is premised on e2e being intractable.
Marlinspike's argument was simple. Levison's site made expansive claims about its security properties. Marlinspike highlighted them. Then he explained how the system could only provide those properties under an "avert-your-eyes" attack model, because it was fundamentally a plaintext-in plaintext-out system. It could provide no security without Levison's own say-so, but could subvert its users the moment Levison's will or capabilities broke.
Levison replies with a series of technical details that are irrelevant to the avert-your-eyes problem. Levison thinks that marking memory secure was a meaningful countermeasure against a state-sponsored adversary (compelled disclosure was his stated threat model), because attackers would not have had the source code. This is a baffling statement in an era where people reverse engineer smartphone basebands for fun, because it's an obstacle that the FBI would have had no trouble surmounting in 1999.
Similarly, Levison's surprise that the DOJ could compel him to hand over TLS keys (in a configuration that Marlinspike points out wasn't even forward-secure --- that is, a configuration that provided sub-Google levels of resilience versus DOJ) doesn't have anything to do with Marlinspike's argument. If Levison's own keys determine the security of the system, it is an avert-your-eyes system. However meaningful you believe avert-your-eyes promises to be, the are undeserving of promotional security copy that discusses the details of asymmetric encryption.
Levison argues that it's unfair to judge his system by the standard of PGP. His system was designed solely to protect emails at rest. But that's a meaningless distinction, obviously so, because Levison had to shut his system down after being compelled to reveal keys that could decrypt prior sessions. Plaintext-in plaintext-out mail encryption is like a bulletproof vest you store in your attic --- perhaps useful for protecting you against bullets flying in your attic, but little else.
I believe we need two kinds of privacy enhancements: laws that constrain the actions of governments and limit the scope of investigations, and better privacy-enabling technology. But I have no illusions about which of those two enhancements users should rely on: they should ignore the limitations supposed for governments, and choose technologies that offer end-to-end security, where the endpoints make the judgement calls about the degree of safety they have, not the operator of the service.
And while that concludes my direct response to Levison's post, I'd like to make a tangential argument:
"I wasn't trying to fix security, only improve it" has for the last 20 years been the siren song of bad security systems. It lured customers into the rocks in the 1990s when it was used to rationalize stack canaries as a cure for memory corruption vulnerabilities, shipwrecked web developers with promises of "smart quoting", got Hushmail customers backdoored, inspired 100 different secret-salt password hashes, installed tens of thousands of packet sniffing "intrusion detection" systems on networks around the globe, and got us elliptic curve-based chat systems... incorrectly implemented in browser Javascript.
Alarm bells should go off in your head when you hear that sentiment spoken aloud. Loud ones. If you start to feel persuaded by it, tie your self to the mast: reinstall GPG, generate new keys, and refuse to send plaintext messages.