The Achilles heel of the CAP the­o­rem

"Impossibility of distributed consensus with one faulty process"?

This is an important result and has significance to your comments and the CAP theorem. Essentially one can't tell the difference between a genuine failure and a slow running machine or busy network.

Thus your solution might work for a very small number of machines all in a single data-centre but for larger installations, failure of machines, routers, switches, cables etc will happen several times a day and thus quorums and clusters become considerably less practical and loose consistency more attractive.

Note also that the theorem isn't just about clustered services in the traditional sense but also services that run across multiple data-centres.

I also have a specific observation:

"....note that quorum solutions exist to avoid that the complete cluster has to be up at the same time."

This is true but they are limited by a number of factors practically:

(1) The assumption that you will have a majority - seemingly this is straightforward but a partition plus a loss of a machine can leave you without a majority.

(2) Getting all members back into sync. Can require all sorts of special admin involvement and it can go wrong.

(3) Performance - quorum protocols especially across enough nodes to ensure survival can be slow.

(4) Ensuring that clients don't continue to make use of the minority during a partition e.g. reporting out-of-date information.

(5) You can have a cluster capable of achieving consensus but you can't reach it because the network is broken between cluster and clients.

Best,