Having read the entire article, I'd say that while it's good to consider the implications of encrypting all traffic (including those mentioned in the article), it's perfectly reasonable to have done so and still come to the conclusion that every single one of those implications are entirely by design features, rather than bugs.

"Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure because of the possibility of government interception. This one is a very old argument, and easily debunked: assuming you allow any encryption at all, just having less of it doesn't make lawful interception any easier, because of course all the illicit traffic will be encrypted. The only thing it does is make encrypted traffic seem more suspicious, which isn't good for anyone.

SNI works just about everywhere these days, and it's quite safe for most services to just turn it on and write off the few systems (IE on XP, and truly ancient mobile devices) that can't cope.

People don't get used to clicking certificate warnings away because browsers have gone out of their way to make that painful, and it should be.

If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it.

There are many folks working on fixing the CA problem, but even without that completely fixed, SSL is still better than cleartext.

All that said, I do think the first section of the article, about unintended affordances (such as emergencies) is worth considering in other technological contexts. That point was made years ago: http://code-is-law.org/