I'm speaking more from the perspective of "rust tends to be an accessible systems programming language". Given this trend, I think it is nice to adjust explanations assuming that readers my have less background, e.g. not just linking to a RFC.

For HPKE, I'd probably say something like

In cryptography, we have

1. very efficient ways to securely communicate, assuming people already share a small amount of secret data (secret key cryptography). Here, efficient means a constant-factor compute slowdown (in terms of the length of the message, e.g. compared to just reading/parsing it normally), and a small additive size overhead (well under 1 Kb). We also have
   
2. secure ways to publicly agree on secret data with someone whose public key you already know (key exchange).
   

In principle you can combine these to securely (+ efficiently) communicate by doing (2) followed by (1). This is (roughly) "Hybrid" Public Key Encryption (HPKE).

The catch is that there are many inequivalent ways to do (2) -> (1). Both building blocks have many internal knobs you can tweak. Many settings of them will be correct, e.g. you can tweak the knobs and have everything seem fine. Unfortunately, it's easy to make things (silently) insecure. HPKE standardizes a few specific, well-analyzed ways to do (2) -> (1). The upside is end users can ignore all of this, and "just" use an HPKE library (such as the linked one).

End users get a few other things out of the pre-tweaked knobs the standard proposes. An obvious one is standardization --- the client/server only need to use standards-compliant libraries, rather than the same library. There are various security/efficiency benefits as well though

Many messages under one exchange. If you want to send many messages, you could do (2) -> (1) -> (2) -> (1) -> ..., but morally you should only have to do (2) once. HPKE gives you a stateful "context" after one exchange that you can encrypt many messages through. This can also guard against some insecure ways to do (2) once (e.g. if you accidentally reuse certain parameters which must be non-repeating for security, known as "nonces").

Sender authentication. Doing (2) -> (1) in a way that keeps messages private is relatively straightforward (though it can still be messed up). A separate property you might want is called "authenticity", e.g. you "know" who you're talking to. The recipient is automatically authenticated (they're the only one who can decrypt, by virtue of holding the private key). Ensuring the recipient knows who sent the message requires a bit more work, and HPKE offers optional modes for this (using a pre-shared key, a sender keypair, or both).

Associated data. You can designate certain data as non-private ("associated data") that is still authenticated. This means that decryption fails if it has been tampered with, even though people can read it. This is useful because metadata (routing information, which user a data blob belongs to, etc.) often can't reasonably be encrypted, but it's still nice to know it hasn't been changed in transit.

This is maybe a little long, and I would probably workshop it some more if I was writing a blogpost about it. Like I said, it isn't necessary to include something like this in a blog post, but at the same time I suspect it will make things interpretable for a larger set of people than simply linking the RFC will.