The atomicity is for the site update.

If I'm deploying to my server, the structure would look like:

  /srv/example.com/prod -> /srv/example.com/versions/1
  /srv/example.com/versions/1/index.html
  /srv/example.com/versions/1/assets/index.12345678.js
  /srv/example.com/versions/2/index.html
  /srv/example.com/versions/2/assets/index.87654321.js

A new version is atomically swapped in by changing the prod link from versions/1 to versions/2. If you request index.html and get the updated version, there's no scenario where assets/index.87654321.js could 404. Serving an updated index.html but 404 for a later request for assets/index.87654321.js is not reasonable. Of course distributed systems are harder but it's their problem to solve.

Note that with a naive web server and the layout above, one could get an old index.html but no assets/index.12345678.js by the time the .js file is requested, but that's less problematic and could be covered by some lingering cache. Or I could simply include the last build's assets as there's no conflict potential.