I understand the mechanism. I wanted to know the reasons for this choice.

Why choose to break user boundaries? Why can't docker images be files in the possession of each user?

They didn't chose to break user boundaries. They chose not to artificially recreate them.

In the shared daemon model, there are no user boundaries. Even if the files belonged to each user permissions-wise, the central daemon running as root would be able to edit all.

I think there's two questions there:

Q: Why not have container builds and runs be invoking-user-specific by default? A: As the adjacent commenter pointed out, this would be an overlay on fundamentally rootful behavior. It would also remove a lot of "works on my machine, works anywhere", since different user accounts running/building containers could be restricted in different ways on different computers, so my "docker build" and your "docker build" might both work, but do different things or fail in different ways. Note that this isn't the same as saying "rootful dockerd is good"; it's not (usually)! That's why rootless docker (https://docs.docker.com/engine/security/rootless/) is recommended in many environments. But even in rootless, the run-user of the container and build are still uniform with the rootful behavior (albeit they require more participation from the daemon-owning user account WRT UID mapping/user namespaces/privileged actions), which I think is a good thing. Rootless docker, last I used it, behaved sensibly re: vs. user container images (kept per-user) and globally-cached layers (removable by anyone), but that may have been a specific configuration where I was using it.

Q: Why aren't docker images user-browsable files? A: I can't say for sure; I didn't build Docker, but I hear the guy who did is in the neighborhood :). I suspect it's a combination of caching (since build stanzas/Dockerfile lines are intended to be proxies for the content address of a layer, there's nothing to gain by making layer caches per-user), implementation convenience, and an influence from the Golang platform wherein (after the age of vendoring wound down) the developer tooling has many convenience layers that de-emphasize user visibility of build/download artifacts a la "go run". Docker goes further, though. And yes, I know that you can get at OCI images/layers as files. But most people don't.