This is framed as a new characterization of the properties of database servers, but isn't just about whether the client waits for acknowledgment from the cluster?
It seems completely unrelated to the server's consensus algorithm. Any client for any of those systems can proceed before the transaction is committed, it is faster but means that your transaction might disappear if the wrong node crashes.
How does the author end up with an empty column for "PC/EL" in their table and not realize that "choosing [low] latency" (by not waiting for acknowledgment) is no longer guaranteed consistent?
It's not about whether clients wait for acks, but rather whether participants of the consensus (instances of the database servers, basically) wait for consensus prior to commiting.
If the client doesn't wait until the transaction is commited, a a client cannot 'proceed', as the transaction is not observable in any node. Giving this guarantee of consistency requires consensus among the nodes, and consensus introduces coordination, which introduces latency. That's the basic argument for PACELC.
It seems completely unrelated to the server's consensus algorithm. Any client for any of those systems can proceed before the transaction is committed, it is faster but means that your transaction might disappear if the wrong node crashes.
How does the author end up with an empty column for "PC/EL" in their table and not realize that "choosing [low] latency" (by not waiting for acknowledgment) is no longer guaranteed consistent?