I think the interesting interplay with this is in "need" vs. "want".

I share the conventional wisdom that nothing, or very nearly nothing, needs these properties. But I don't think it's unreasonable that people have been looking around for things that want them.

Why would you voluntarily want a data store that can't store sensitive values?

I don't know, but I also think it's reasonable for people (who aren't me) to see if they can figure out use cases where they do want that, and actually make them work. I'm not particularly bullish on any of these projects, I just also think that thinking outside the box in this way is one of the ways that interesting things come about.

I'm personally pretty happy to be conventional and milquetoast, but I think it's fairly self defeating to be stuck in the box of "only projects that work on traditional database architecture could ever make sense", so I'm glad people are out there trying different things, even when I think they're pretty likely to fail.

I can think of two reasons:

1) The data store offers some other interesting property that necessitates this tradeoff.

2) You want your data store to be transparent/auditable by anyone.

> 3. Data records, once written, are never updated or deleted?

This is not a requirement for any blockchain with smart contracts.