It is often the case when people say that they "love animals",
that what they mean has nothing to do with caring about the well-being of said animals.
For example: "I love animals, but I also love meat",
unless followed up with "so I avoid eating meat",
roughly translates to
"I like looking at animals.  I also like eating them.
How they are treated or whether or not they want to be eaten is not something that I concern myself with."

When people talk about things being "natural" they're not talking about facts or measurable things.
They're talking about how they feel about the thing.
You could define naturalness in terms of measurable things
(such as how many steps of refinement it had to go through,
or what impact it has on the ecosystem when you dump it all over).

I was thinking about blockchains in the shower
and comparing to Git,
as in how they can be useful when you already have a version control system.
And in my mind there's this bifurcation between systems used to store *actual* history and systems used to store *ideal* history.
And I feel like Git makes a good patch-sharing system.
You can make a feature branch and put all the changes just related to that feature
(or bug fix) on it, and if your code is well factored you might be
able to get away with having that branch be independent of other features,
and to that end you might branch it as far back in the history as possible.
And when everything works well and you do a traditional merge, you're
preserving both actual history (who authored what commits when based
on what other commits) and an idealized history
('we added this feature to master').
But sometimes things don't work out so well, and if you want to create
an ideal history (because that's easier for everyone to work with),
you go and do a bunch of rebases and cherry picks and squashes and things.
But those no longer point to the actual history, so you lose that information.
Blockchains are really good at storing *actual* history, since nodes
will pitch a fit if you try to build on top of some other chain
(in most blockchain designs).
So one use case for using blockchains for storing data would be to
store the actual history of changes to your system, which is useful
for auditing, but would also allow you to recreate your database if
all data was accounted for in there.
If you're managing a complex system with interacting parts
(like code for a PHP web application)
you would probably want to use Git and when you push a change,
store a reference to the new HEAD of your codebase in the chain, too.
Which almost seems redundant, but the blockchain and the Git repository are serving slightly different purposes.
esp. if said blockchain forces you to sign ammendments to it or something.