The counting barrier in the paper I linked is meant specifically for shared memory multiprocessors, not distributed systems, so what you're saying makes more sense. Both the counter and the state are shared variables across all threads. This clearly doesn't scale well with number of threads/processors due to cache contention, but the idea is to have a "simple" barrier. There are a few barrier implementations that operate via message passing further in the paper.

But either way, the counter can never be 6 since the max counter is set to the number of threads, and each thread at the barrier decrements the counter. Once a thread is spinning, it doesn't care about the counter anymore, only the state. Once the last thread reaches the barrier, the state flips, and all threads awaken. Each thread maintains a local copy of what the "reversed state" should be to awaken. If one thread gets preference and advances to the next barrier, it will decrement the counter it reset and will spin for the global state to flip again. So even if it reaches the second barrier before any of the other threads awaken from the first, it will wait for the rest of the threads to catch up.