Nowadays, most sites use HTTPS and set HSTS headers, so the odds that
someone can eavesdrop someone else's connection is very low
This assumption is scary bad. It does not matter how many sites set HSTS headers if HTTPS itself cannot be depended upon to provide endpoint to endpoint security. And it can't. Sadly.
Have you heard of a TLS Interception Proxy? They are commonplace. Deployed in schools, universities and libraries and used by employers and coffee shops alike, these hardware proxies (such as WebTitan Gateway or Cisco ironPort WSA) render HTTPS null and void, because during the "secure" connection they introduce a dynamic certificate pretending to be the destination website's official certificate. My browser doesn't know the difference, and if I didn't know better then I'd trust each HTTPS connection on its face.
Initially, HTTPS was designed to prevent MiTM attacks. Today, the TLS Proxy IS the MiTM attack! Whether you're reading your email or checking your bank account balance, you should be under no illusions that HTTPS is actually doing what you expect it to do, that is, secure your connection from eavesdropping. And unless you're connecting through your home WIFI & router, or unless you're using a decent VPN, get used to the fact your connection is probably being decrypted and re-encrypted on-the-fly, without your knowledge or consent.
There's little need to consider the "other threats" suggested by the OP until bona fide encrypted connections are the norm. Currently, they're not, and HTTPS is a farce. (To prevent eavesdropping, use a reliable VPN run by a company that won't store or release records. Use TOR to make the connection even better.)
Why do I assert that HTTPS/HSTS is not really a web browser's security blanket? Because 3 years prior to OP asking the question, it was already exploited and defeated. And just 2 years prior, it was subverted. Further, certain popular implementations of SSL were proven broken as far back as 1998. Even certificate authorities (CAs) are not to be trusted. A brief timeline:
- 1998 - Daniel Bleichenbacher describes a successful attack on PKCS #1 v1.5, the (then) RSA Encryption Standard (at CRYPTO 98); an assault thought to require a million attack messages to exploit
- 2009 - Moxie Marlinspike creates SSLStrip to attack HTTPS (demo at Black Hat DC 2009)
- 2012 - IETF gives us RFC 6797, which implements HSTS, designed to thwart SSL stripping
- 2012 - Graham Steel publishes a paper (at CRYPTO 2012) demonstrating Bleichenbacher's padding oracle attack needs less than 15,000 messages—not one million as originally supposed
- 2014 - Leonardo Nve creates SSLStrip+ to avoid HSTS (demo at Black Hat Asia 2014)
- 2015 - Sam Greenhalgh demonstates HSTS Super Cookies, showing how the HSTS security mechanism is easily subverted to be an invasion of privacy
- 2015 - Google realizes Symantec and its subsidiaries have fraudulently issued over 30,000 security certificates without proper audits or disclosures
- 2016 - Google institutes a published blacklist of untrustworthy certificate authorities, dubbed Submariner
- 2017 - Ars Technica reported that major sites such as Facebook and PayPal tested positive for Bleichenbacher's critical, 19-year-old vulnerability permitting attackers to decrypt encrypted data and to sign communications using the sites' own secret encryption key
- 2018 - Google updates Chrome to version 70, in order to deprecate trust in the Symantec CA (including Symantec-owned brands like Thawte, VeriSign, Equifax, GeoTrust & RapidSSL); and Mozilla follows suit
- 2018 - Adi Shamir publishes a paper detailing that modern implementations of PKCS #1 v1.5 are just as insecure against padding oracle attacks; affecting protocols & services like AWS, WolfSSL and the latest version of TLS 1.3 released in August 2018
Currently, to battle issues like "transitive trust," subCAs and the shenanigans of CAs who issue them, e.g. GeoTrust, etc., we have the DANE protocol, designed to "secure" the security certificate—the irony is not to be missed here—via DNSSEC by allowing domain admins to create a TLSA DNS record.
If DANE were widely implemented, I might be more inclined to agree with the OP's low threat assessment, but using DANE means a site needs to DNSSEC-sign their zone, and as of 2016, only about 0.5% of zones in .com are signed.
As an alternative to the poorly adopted DANE, there are CAA records, designed to do the same thing, but the latter mechanism isn't any more entrenched than the former.
It's the end of 2017, and the odds are extremely good someone can eavesdrop your HTTPS/HSTS protected connection.
UPDATE DEC 2018: Whether it's insecure protocols, poorly implemented secure protocols outside the user's purview, secure technology awaiting mainstream adoption, fraudulent authorities issuing unverified certificates, or good old-fashioned hardware-assisted eavesdropping, it's the end of 2018 and I still maintain the odds are extremely good your HTTPS connection is not protecting you.