Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis.
HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)
If these things are attacked, your security is not worse than HTTP.
HPKP and HSTS fix the problems you've described.
And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session.
For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat.
This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).
All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change.
You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one.
HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.