Alice, Charlie, Alice, Bob, Bob, Charlie, Bob, Charlie, Alice, ...
First u receive a block (A) from Alice.
Then u receive a block (B) from Charlie.
Then u receive a block from Alice, but she wants to eject Charlie from the queue and references block A as the previous block. Ur soft will ignore her block and will wait for the next forger. If the next one is Bob and he references block A too then ur soft will ignore this block too. After a while there will be a turn of Charlie.
As we can see bad guys can't "punish" good ones. The effect is exactly the opposite.
So their technical answer is something we had considered and rejected on the following principle (though there is still some debate with Dan N.)
1) What if Alice is acting properly and Charlie was just 'late' producing his block. The network will split because half the nodes will receive a block from Charlie before Alice's second block and half will not.
2) What if you are a new node and you first connect to the network. You see two chains, how do you decide which chain is the 'best' chain?
3) Since everyone is receiving blocks directly from certain nodes and knows when they should be receiving them, then DOS is a huge vulnerability.
So given these issue their consensus algorithm depends upon the majority of nodes maintaining 100% uptime and in the event of a network split has no legitimate way of identifying the best chain without manual intervention.
Now clearly they are probably suffering some of the same challenges we are with explaining things like DPOS. So I am going to give them the benefit of the doubt and hope someone will cross-post this so they can answer it. If they have solutions to 1, 2 and 3 that are viable I am very interested.