If you don't disclose the vulnerability, users are potentially open to attack because you didn't tell them about a vulnerability that you knew about. If you do disclose the vulnerability, you potentially alert attackers to take advantage of a vulnerability in the short time before users can address it.
From the perspective of someone discovering a vulnerability, disclosing it is the more ethical thing to do because users should know that they are vulnerable and have the opportunity to prevent harm to themselves, even if it means making a service unavailable or degraded for a short period. If you tell them about it and they are attacked, that's on them. If you don't tell them and they are attacked, that's kind of on you.
I agree there's some grey area if there no known exploits, but a lot of times these vulnerabilities are found in response to an actual out-in-the-wild exploit.
The bad guys will figure out how to go about exploiting the vulnerability almost immediately after the patch releases, if they aren't already exploiting it. It makes 0 sense and protects 0 people to hold onto details after the patch is made available.
Also, how does it ever help anyone to have the details released? It only helps the researchers for PR and bad actors, never the users who need to apply the patch (and often need some time to, one can't just upgrade something out of nowhere in less than 24 hours).
It is just as applicable to closed-source as it is open-source. The people who are good at developing exploits are, unsurprisingly, good at reverse engineering and using disassemblers. It is generally trivial to figure out exactly what issues a patch is fixing if you are an experienced reverse engineer, and it's a short journey to developing an exploit once you have that knowledge.
>Also, how does it ever help anyone to have the details released?
Because the details will illuminate many potential indicators of compromise, which can be used throughout the defense stack (e.g. YARA rules, ASA rules, etc.)