It makes the "hair on fire" nature of critical security vulnerabilities unavoidable. It's much easier to sell an outage to management if you can more easily demonstrate that anyone could have this exploit (which is true regardless).

"Bad Lock" - maybe there's a clue

No. As an admin I'd rather have the details so I can make sure even my non-standard, non-patchable, fleet is safe. (Where I might need to implement custom firewall rules to inspect data for bad patterns, etc.) Once my coworkers and I protected our ISP's customers against a worm at the external boundary. If we'd only had the patch and some sanitized information to work from that would have rattled around our system for months until we'd harassed every customer to update and would have caused tons of harm in the meantime.

I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand.

Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)