@DLE -[F]or anyone who wants his or her site to be bulletproof[, the] WordPress [model] simply can’t deliver that promise.

While that is technically true, it is true only because "bulletproof" is not available.

There is literally no website, anywhere, at any level, that is bulletproof. Not the Pentagon, the Kremlin, the CIA, Microsoft, Google, you-name-it. They've all been hacked. Not 'could be', not 'are vulnerable', but, quote "have been hacked". Repeatedly. Every one of them.

There is no amount of money or expertise that can make any website bulletproof.

There is no alternative to WordPress that can make your website bulletproof. Drupal? Joomla? Bulletproof? No.

What can we do?

1.) Do backups.

2.) Keep copies of the site. Localhost. Mirrors. Duplicate hosts.

3.) Learn to actually restore from backup. Rebuild. Mirror. Localhost.

When an exploit goes ripping through gigabytes of stuff in a government site, or in a major social media site, do they "fix" all that mangled content? Heavens no. It could take centuries. No - they just switch to a copy.

If you are fairly modest in scope, you just perform backups, and if something bad happens, you wipe the site slick, and rebuild with a fresh copy of WordPress (or Drupal, Joomla, etc) and your backup file. If you are getting pretty seriously-big, then you make mirror copies of everything, real-time.

In a few hours, a few days, you're back in business. "Fixing" compromised website is oh-my-gawd the hard way to do things.
==========

If we don't quite understand a plugin or theme, we don't contact WordPress about it, because we know that it isn't theirs, they didn't write it, and they aren't supporting it. We know that questions about a plugin/theme have to go to its author.

The plugin/theme author is responsible for her own code. It is our decision to put that author's code on our website. We the site owner is responsible for 3rd-party software additions that we make to WordPress. Not WordPress.

Many of us ought to do more looking-into a plugin, instead of just reading a one-line blurb, and clicking "Install". (This is a personal weakness of mine ... but these days I don't activate them right away. I stick them in 'quarantine' while I read their docs, peek at the code, and do some searches using 'plugin-name' with words like 'broken, "doesn't work", problem, sux', etc.)

The problem of 'dirty' plugins and themes is not nearly as big as it once was. WordPress made the Extend Library, so that they can enforce some basic standards, to weed out obvious bad apples. This is a huge help. Problems with add-ons are diminishing.

It helps to pick plugins that are small & simple, and/or broken down into small & simple components, which work together in a transparent way. If the code is small/simple, then it is harder to hide crap in it, and - most importantly - it is far more likely that someone knowledgeable has or will spend the time and make the effort to study the code and understand what is there & how it works.

Hairball, bloated, Gotham City code makes the task of investigating a plugin too much of a challenge. People who have the ability to do this, have too many other things to do with their lives, than to get tied up doing heavy-duty, long-term forensics on a freakin' bad plugin.

Go for the small & simple plugins. Make a conscious effort to replace the big, does-everything plugin, with several that do one thing each. There is a logarithmic/geometric complexity-cost, with do-everything plugins.

When an issue arises with a small code, it is approachable/addressable. When the big one goes bad, the effort to tackle it is prohibitive.
==========

My condolences, DLE, on the bad experiences you've had with WordPress. I know these things happen, and that the personal impact can be severe. My apologies, too, for riffing off on your straight-up report with a bunch yeah-buts & ya-knows ... but you gave me such a great opportunity. :)