“The problem with this mixing of atomic/non-atomic operations on the same types/data is that you loose all benefit of statically ensured atomicness in the first place.” - agreed, hence the name of the package is UnsafeAtomics.jl. Caveat emptor, use with care, etc.
That said, if you take care to add a fence in the right places, then you can (manually) ensure that the code is safe. E.g. if all of this is buried inside some function’s code ...; use_unsafe_atomics(); atomic_fence(); ... then the function is safe to the callers.
Sure, copying all the data between the atomic-only and the normal types is possible, but in my case (large vectors) this would be painful (performance is the name of the game here after all). Especially using the existing Atomic types which require a heap allocation for each value (shudder) - but even if/when @atomics avoids that, it would still defeat the purpose of the whole thing.