Honestly, it seems like the right answer here is for distros to automate and streamline the process of releasing security updates so that an embargo period is unnecessary. The embargo can't be perfect, anyway - the distros need to publish their packages to a public repository, and the customers who actually run the code will take some time to pick up that update and install it everywhere. So the embargo period isn't the goal in and of itself; it's a tool to ensure that the time between public awareness of the vulnerability and fixes being applied to the actual systems is as small as possible.

As I understand it, the reason for the embargo is to provide time to validate the fix (ensure that it fixes an actual bug, it really fixes the bug, and it's not a duplicate of something already tracked), package the fix, minimally test it (it cannot be fully tested by the distro, because the fix is strictly embargoed from all customers), and prepare an announcement with relevant information including a CVE ID. Most of these steps can be automated - compared to when the linux-distros list was created, we have not just cheaper / faster computing resources but also fairly easy ability to get those resources in parallel instead of serial form. Even ten years ago you'd probably want to run builds on your own resources; now it's sensible to run at least tests and probably builds too on a large cloud provider's resources, and they will sell you 1000 computers for one minute for the same price as one computer for 1000 minutes. Especially if a patch against a stable release is provided, distros should be able to the computational work in much less than an hour.

(Of course, I'm sure I'm missing something practical in this "why don't they just..." analysis, and I'd love to know what it is. :) )

That leaves the work of backporting the fix, which really requires some human review if not action; coordinating and validating the fix; and assigning a CVE ID and writing up the vulnerability. For established projects like curl, it makes sense to entrust the upstream author with the coordination and validation work and perhaps to pre-assign them CVE IDs. (The CVE assignment process was a mess for many years, but I'm under the impression it's better now, and it's certainly a fixable mess either way, so it's not a good defense of a long embargo period.)

So that leaves just backporting the fix to the distro's choice of stable branch, which certainly requires human effort, but not multiple days of effort. For the commercial distros, they should be able to have a couple of engineers with an on-call schedule and commit to a response time in hours.

At that point, your embargo period is shorter than the likely time it will take customers to notice and apply the fixes, so you may as well get rid of it.

Note that this proposal doesn't impact embargoes for the purpose of researching the vulnerability and developing fixes - it allows the upstream project to continue to have its own internal embargo period for however long they like, and it also allows distros to accept confidential security vulnerability reports and relay them to the upstream project. That embargo period is the one at the heart of the "full disclosure"/"responsible disclosure"/etc. debate. But the distro embargo period, where sufficiently large redistributors who are neither the upstream maintainer nor the party running the code have some extended time to prepare updates, doesn't seem like it's inherently defensible under responsible-disclosure arguments; it's just an artifact of the fact that preparing updates takes time.