Not just `FROM scratch` but also in other contexts. For example:

I wrote my own password manager which lives on a USB drive. Since I compiled a static binary, I can execute it on any Linux machine.

Running static binaries in FreeBSD's Linuxulator is easier. The Linuxulator is a separate set of syscalls that get used when you attempt to run a Linux binary, so a static binary will "just work" for the most part (unless the program needs special filesystems like /proc or /sys). A dynamically linked binary means I need to make sure I have any necessary Linux libraries in the proper location and the Linuxulator's `ld` working properly. Updates to these libraries can then make something that used to work, suddenly stop working. Certainly not an insurmountable task, but there's so many fewer places where things can break when you're just running a static binary.

I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).

...or people who had a test/deploy/debug cycle on environments that necessarily had no layer cache (ephemeral VMs, one-shot kubernetes clusters, OpenWRT routers that lost the layer cache on reboot). Or people with network-constrained traffic from registries or mirrors thereof.

Or people in environments that took container security findings (perhaps too) seriously and were tired of triaging endless reports for random dependencies in "FROM ubuntu" containers, and wanted a default required-by-policy base image that didn't come with the world.

Or people who needed a relatively full-featured build environment against musl without having to do bizarre incantations in e.g. a Fedora image to switch away from libc while still being able to link against other system libraries.