The evil CAP theorem enters the town here. Consumers want things to work fast, it doesn't fit the decentralized approach.
> Databases we have today aren't designed for the kind of consumer applications we use today
Consumers don't really care what kind of database do you use. They want to open the page and click the button, quick, now.
I think we have to distinguish 'decentralized' from 'distributed' in this case. In a decentralized approach we reduce (by many orders of magnitude) the size of data we're dealing with. Locally installed/browser-based applications only have to deal with data that's created by, or directed at that user (and locally stored).
Add: For a number of applications, hard consistency guarantees are overkill. You could totally live with eventual consistency (some don't even need that). In fact, other than e-com and banking I can't think of any of my daily-use apps needing such guarantees. And indeed, decentralized data storage is a bad fit for banking and commerce.
You should note most consensus algorithm designs start with sharing a single ‘register’ (or ‘value’).
Most banks were doing “decentralized” relaxed consensus from the beginning of “banking”. Local office accepts your deposit of your check. “Funds available next day”. Because by “next day” they have confirmation from counter party for the funds.