Sure, let’s create another one and expect it being used by all othe those who use existing stabdards.
It would be great to understand the exact specific motive which drives it instead of converging on an existing standard.
The idea here is simply that the IETF is going to need to do asymmetrically encrypted message exchanges in future standards, and CFRG's job is to make sure there's a well-vetted, carefully designed construction they can pull off the shelf to do that. There is not, in 2024, an existing reference point for this construction that IETF WGs could use, if only because of PQC.
You have to wait for an IETF WG to actually use HPKE before you get to complain about the standards proliferation; it'll be that "customer" (of CFRG) standard that will need to be judged on whether further standardization is a good idea.
It doesn't make much sense to dunk on the actual cryptographers at IRTF, who are more or less just explaining to the IETF WGs how to do cryptography properly.
(I say this as someone who considers themself an opponent of all cryptographic standards bodies).
The idea here is to write a clean, easy-to-use spec for hybrid public-key
encryption. (We're using the name "ECIES", but as the draft notes, the
idea is clearly more general.) This primitive has come up in IETF work on
MLS and ESNI [0][1], and in several other protocols, e.g., through the NaCl
"box" API [2]. The hope here is to have a single spec that unifies these
ideas and can be the target of formal verification.
I admit that there's a little bit of XKCD#927 here [3], but I think there's
good work to do here in terms of addressing some more modern use cases
(e.g., streaming / multiple encryptions from a single DH) and possibly
enabling better post-quantum support by generalizing to KEM instead of DH.