Given that "unsecured" means "data are accessible and modifiable by anyone", creating tremendous externalities for all referenced in the data, , I'm happy with deletion.

FTA:

One of the first publicly known examples of a Meow attack is an Elasticsearch database belonging to a VPN provider that claimed not to keep any logs.

In some cases, I might be tempted to agree with you, but this is blindly being applied by an automated attack. What if some of that deleted data is volunteer-canvassed anonymized survey data of homeless people, and its loss sets back a homeless relief program by months, resulting in several people freezing to death this winter?

The data may be modified at any time without a trace, rendering it void.

Secure your damned database.

The fault and responsibility lie with the deploying organisation and tools vendor. Meow is just the messenger.

But if they had used the password changes API to assign random passwords to all accounts, as suggested, then the data couldn't be modified. Am I missing something?

Parent's point is that any conclusion one could make from the data is worthless because, being public and unsecured, it could have been modified by any Internet user at any time before a password was set.

Correct.

My understanding is that password-secured DBs aren't vulnerable to Meow remediations.

Then people should feel bad their negligence did cost lives.

Both the DB admins and the attackers should both feel guilt. However, if the attackers simply assigned randomly-generated passwords to all of the accounts, then no data would be lost and the DB admins would still have their DBs temporarily become inaccessible while they figured out how to force-reset their passwords. If you're going to go for disruption, I think the suggested lockout gives a much better ratio of good being done to potential damage being done.

Something tells me that this level of pain would prove insufficient for education.