So if there is no proof of work how do you avoid forks? The author says something about splits being detectable but that doesn't really help us decide on which side of the split is correct.
There are two things you have to trust, which I mention in the post.
1. That the node is not denying writes. (What's sometimes in blockchains called censorship.) If the node just didn't run your request, you'd be locked out with no evidence. It's not unsolveable, though - you could combat this by using a 3rd party proxy which records the traffic, and thus can back up your claim that you're being censored.
2. That the node won't just shut down. To combat this, you'd need a procedure for moving to a new hosting node. Not impossible either, but you'd need to decide for your userbase what kind of process would make them most comfortable. The blockchain state is there to be cloned at any time.
At this point the validators compare notes and gossip a proof that the node's been acting up. And then they need to elect another node, which requires... consensus!
Oh and the central node can also become unavailable and DDOSed, how are you going to add transactions to the ledger then?
If it handles transactions faster, better, cheaper, and with less emissions, then so be it.
Unfortunately bitcoin's popularity/ubiquity makes it superior (for the time being) and hard to unseat. Other (decentralized) altcoins make really great improvements over bitcoin but never became (and perhaps never will become) as popular as bitcoin.
If you have hundreds of known, diverse nodes distributed globally (run by very different institutions like Harvard, Bank of America, the Vatican, the Red Cross, the Gates Foundation, the House of Saud, etc. etc.) they can all watch each other, and the odds of them all going offline at the same time or cooperating to deny a specific user's transactions are very low.
This is essentially how CT-logs work, where we consider it sufficient to detect a falsely-issued certificate, even though we cannot prevent such issuance.
Forks are ok as long as they can be merged in the short term.
If something forks for a long time and stays forked, there is hardly any reason to establish a total order during the merge!
Think of an IRC netsplit for example. One that happens for a few seconds may attempt to merge back the chats in some fair order they were made, in diff forks.
But if the netsplit happens for a whole day, or month, no one really gives a crap about ordering messages across forks. The merge is too complex! In fact, the resulting conversation would be MORE nonsensical than if you correctly rendered the split conversations as a DAG in the client.
Similarly, if bitcoin forks into bitcoin cash or whatever, and enough validators accept it, I get to "double-spend" my new money now. Proof-of-work is no panacea. If we religiously want consensus then no transaction can ever be truly confirmed - there is always a chance some larger fork comes along and undoes all transactions on my fork going back a whole month. Interplanetary File System has to deal with this.
The problem is that we still haven't evolved our thinking about currencies as DAGs and keep worrying about the double spend problem and turn to global consensus to fix it.
If the answer is to stop caring about double spend, how do you anticipate that working?
What you should do is have each community have its own internal currency, and then have global payments be powered by a federated system. Like the internet works.
Typically, that period is until the next consensus. In Ripple, the consensus eventually takes place but sometimes may take up to a minute. In Bitcoin it may take 30 minutes. You are never quite sure that everyone "phoned in", but presumably if the network participants announce themselves on the network then you can know when a supermajority has "phoned in". If they haven't - you've got a fork baby.
You can also get a fork if they phone in but start a second consensus somewhere else lol.
This is rather unique to the case of currency though. Specifically, the history of transactions determines which future transactions are possible. Instead a system that only records promises (but doesn't allow transfer of such promises) would work without centralization. If I promise something to 2 different people I remain on the hook for that promise. The fact that I am effectively 'in debt' on the system isn't an issue because the system gives no guarantees on people meeting their promises.