[my personal opinion here, not on behalf of anyone else]
The overall way WordPress leadership handles plugin security is very inadequate. To me it appears to lean really hard on ‘security through obscurity’. It is a constant source of background stress.

The idea that plugins can be ‘de-listed’ without centralized and widely available logs of this type of event is totally irresponsible and I would challenge anyone involved to justify it. How dare anyone impose such a policy without any valid way to flag this within the sites using pulled plugins?

Most of my experience has been over on the Drupal side. Drupal issues core security alerts when underlying libraries have small vulnerabilities, with no fault on the core developers. (for example the recent announced jQuery prototype vulnerability triggered a Drupal core security update).

Has WordPress really been honest enough about underlying library vulnerabilities? Has WordPress really done everything possible to flag people when bad plugins are enabled, as soon as possible?

When a plugin has a security vulnerability is there really adequate notification inside WordPress? Drupal hollers at you when this is the situation you are in, which is a responsible approach. This has been available for many years and it could easily be made available properly inside WordPress without having to go thru multiple paid third party vendors to vet everything.

Likewise the Drupal security team will step in to pull modules or themes that have vulnerabilities, throw red flags all over them, including inside all the sites running them, with emails auto triggered from inside the websites to warn the administrators after cron module update check. This is an approach that actually respects the people building and maintaining the websites as well as the people that find the vulnerabilities and save us all from hacks.

I don’t understand the WordPress world side of how these security issues are organized. In Drupal the security team is large and advanced, it has purview to step in on all these situations in the event that a module or theme developer can’t or won’t. It is also separately managed from the general module and theme administration world.

I can’t say I entirely agree with PluginVulnerabilities approach to the matter but it mostly is a consequence of the inadequate attention and structural necessities paid to this issue by the community management for many years.

PluginVulnerabilities is forcing the community to take a harder line, move away from the pernicious and extremely flawed security thru obscurity approach, and secretive de-listings that don’t protect existing sites! It is essential that people are notified of vulnerabilities as soon as possible. Making PluginVulnerabilities sit on the vulns is harmful to everyone, but under the current philosophy it seems to be regarded as what people want them to do. (and of course every day that PluginVulns has to sit on a vuln and not notify their customers due to the expectation they are supposed to be hush until someone fixes the plugin, is understandably a very tense situation for any security provider to be in!)