This is a good opportunity to assess what parts of your own online activity could be impacted by an attacker in the middle (assisted by a BGP leak or otherwise) and, if you're a service provider, how you can protect your customers.

At first pass you probably use HTTPS/TLS for the web, and you know that you shouldn't click through invalid certificate warnings. So the web, tentatively, looks pretty safe.

Email jumps out as vulnerable to eavesdropping, as we largely use opportunistic encryption when transferring messages between mail servers and an on-network-path attacker can use STARTTLS stripping or similar techniques. Most mail servers happily send using cleartext or without validating the TLS certificate. Check that you and your counter-parties are using DNSSEC+DANE, or MTA-STS to ensure that authenticated encryption is always used. Adoption is still quite low, but it's a great time to get started. Watch out for transactional email, like password reset messages, which virtually never validate encryption in transit (https://alexsci.com/blog/is-email-confidential-in-transit-ye... ; instead use multi-factor encryption).

TLS certificates themselves are at risk, unfortunately. An attacker who controls the network in-and-out of your DNS servers can issue domain-verified certificates for your domain; even removing protections like CAA records. DNSSEC is the classic solution here, although using a geographically distributed DNS provider should also work (see multi-perspective validation). Certificate transparency log monitoring should detect any attacker-issued certificates (a review of certificates issued for .ve domains would be interesting).

Ideally, we should build an internet where we don't need to trust the network layer. A BGP route leak would be a performance/availability concern only. We're not there yet, but now is a great time to take the next step in that direction.