It removes the references to the base image.

I don’t see any benefits. Security scanners have a harder time to track issues, because they can’t just detect the image is depending on an insecure base image.

It also strips the possibility to deduplicate some base layers, or a partial pull if you already have one of the base layers in the cache (Debian or Ubuntu are very common, you might have even the exact same version already in the layer cache).

I suppose the goal is not inheriting environment variables, entrypoint definition etc, not sure

Not an expert but I believe the first approach doesn't inherit the metadata, configuration, or layering history from the original image, it just copies the files and folders.

It's different in that it's creating a new unique intermediate layer, but admittedly I'm struggling to see the value for most workflows. I assume there's an important detail I'm missing, as is the usual case with interesting Dockerfiles.

I think it's meant to remove a layer, as you're modifying the base layer rather than altering it through a second layer. Probably to limit size. (but that's a theory)

I did this to prevent inheriting environment variables from the base image. Unfortunately Docker does not provide a way to do this when using FROM.

The first example collapses all the layers into one, which can result in a smaller image than the second

If a layer creates a file and then a subsequent layer deletes it, the deleted file is still present in the image taking up space. If you squash the layers, the deleted file is gone

“scratch” used to be an empty layer, but in newer versions is now just syntax to state that you want a layer without a parent layer