Users care more about convenience than privacy, open protocols, quality, or long-term financial stability at least at the very beginning.
Furthermore, the "at least at the very beginning" qualifier can be dropped. Due to network effects the very beginning is all there is.
(This behaviour actually makes perfect sense. When first trying out an app the most likely outcome is that it doesn't work for you, so you don't want to spend more than a few minutes researching it and setting it up.)
Open protocol designers need to be aware of this when competing against centralized products. It has to be a top strategic consideration. If it's even a secondary consideration that's disastrously too low and the protocol won't succeed on the market.
One way to think about this is a convenience gage, analogous to the weather gage from the age of sail. Don't think about convenience as a fixed attribute of the protocol. That would rule out the part of the solution space that has better privacy, standardization, quality, and financial stability for the entities involved, but is a hair less convenient for users. Rather, think about convenience as a mutable attribute of the situation. Design a protocol that starts surprisingly convenient and has a mechanism for ratcheting new user convenience down once the network effect of the protocol is active.
I think, in general, our software benefits when we use as few languages as possible, because programming languages have such powerful network effects. Embedded DSLs are usually strongly preferable to freestanding ones because we get to reuse so much knowledge and infrastructure.