Well, using a strong word like negligence is perhaps strong... On the other hand, if it is, I am not sure what I would call shipping a database setup that has no provisions to keep your data in any way; aside from never, ever (ever, ever) turning off.
What I am talking about is etcd-operator. It is a Kubernetes role to install/manage ETCd. And by default, from the role, it appears to have its example manifest set to have a VolumeMount (great?) set to EmptyDir (oh no). So it will just willfully throw your data away if one of the pods running ETCd restarts. Bearing in mind that the default cluster size is 3 instances.
Yes it would just be that pod's data. But if you lose another, say 2 pods running on the same underlying hardware that dies at the same time...
Then you have a cluster that you can only read from, unless you back the cluster up from the remaining node; blow away the cluster; and rebuild the cluster, and restore data to it. Since the cluster with only 1 node left has no possible way to restore quorum, the other nodes are dead and have no data; it can't possibly write new systems into the cluster.
There is also the case where you restart all of them accidentally, or say as part of an upgrade. Then your data is just gone into the ether.
So, is "Negligence" applicable? I think it is; sure it is not "production ready", but that does not often stop people from running things in production. The fact it doesn't keep any of your data isn't advertised on the tin, as a warning for people. It's burried deep in a "todo" file. Like, who wants to keep their data anyways?
Anyways, to the none-folks out there reading this, think before you release shit to the world with a loaded gun taped to the user's head.