I think this goes back to an important theme in the class which is the difference between abstraction and implementation. Just like Cilk is an abstraction that can use threads for implementation, similarly it seems like "atomic" is an abstraction that can use locks for implementation. But it is wrong to equate the two because "atomic" likely uses locks in a more specific setting where there are conflicts with at least one write to the same memory address whereas if an engineer used a lock in place of atomic, they are locking regardless of whether it was actually such a conflict. Similarly, if an engineer used a thread instead of cilk_spawn, they may be missing out on features specific to Cilk's implementation.

viklassic brought up a really good parallel with Cilk. The distinction between implementation and abstraction is especially tricky in this case because it's easy to imagine implementing atomicity with one global lock. However, that's not the only way to implement it (and my guess is it's a fairly inefficient way overall)! Vice versa, locks are a powerful primitive that can be used to build abstractions and complexity, and can accomplish things that "atomic" can't (like finer levels of granularity), but are ultimately a tool, not a high level approach.