Because it's not always so simple to structure your solution in a way that's amenable to having multiple processors work on the data without cache conflicts. Locks are extremely common, they are not a "workaround" rather just another of many tools to control concurrency.
Also, few or no CPUs can perform atomic operations on 64 bytes of memory without using transactional memory (which has its own drawbacks), and in any case atomic operations and cacheline alignment don't save you from cache misses and invalidations if CPUs operate on the same data.
You don't modify the entire 64 bytes at the same time. That's why you fill it with atomic variables that you can modify _without_ locking.
You need the array to contain structures that fill the cache line to avoid invalidation when two cores write/read structures close to each other.
When two cores write/read to/from the same atomic variable in the same structure you of course need to know what the consequences will be, but most of the time it will only result on gliches and not crashes... say if the position of a player is updated by the physics and incoming network at the same time and read by the render core... the player will glitch to some location that might be wrong for the other writing core so you have to make sure that is handled to not behave in a non playable way, but performance on the CPU is the _only_ bottleneck we will ever have and we're already there.
You could also look at Javas concurrency package. It's mostly atomic.
That way you avoid cache misses and cache invalidation at the same time. And your software can run at full speed across multiple threads/cores.