Improving the handling of embargoed hardware-security bugs

It is very unlikely that the attackers gain will access to information about the vulnerability at the same time that the vendor does. If they already have this information at the point the vendor discovers it, then a delay from the vendor makes the situation only quantitatively worse, not qualitatively -- the time the attackers can exploit it gets longer due to the embargo, but it doesn't come into existence due to the embargo. If the embargo time is short compared to the length of time that the exploitable bug has existed, then it's unlikely that the embargo causes a substantial increase in the time the attackers can exploit it, and also unlikely that the attackers will discover it during the embargo period if they haven't already discovered it.

Meanwhile, you have to consider the value of lifting the embargo earlier. Lifting it early doesn't necessarily mean the end users are then "safe". If there are essentially no practical fixes without changes from the manufacturer, and the manufacturer doesn't have those changes ready, then lifting the embargo only helps attackers without helping users protect themselves. Even if there are practical fixes available, rushing them out before they are "fully baked" increases the risk that they are insufficient or buggy, at which point we can basically assume that the attackers will find the bugs in the patches before they can be patched, and that's almost as bad as lifting the embargo without a fix.

And, of course, there's also the observation that there are certainly plenty of "less skilled, less informed, slow, etc." attackers in the world -- and, once the embargo is lifted, they too can pretty quickly start exploiting the bug. So even if a few highly-skilled attackers already know of the bug, lifting the embargo without a reliable fix in place still has high cost.