If people are surprised by this - and clearly a non-trivial number of people are - then even if the behavior works as intended it should be indicated in the UI at critical points.

GitHub is not simply a UI to actual git repositories it hosts. It also carries a lot of data that is not stored in the repository itself. The UI deliberately blends the two types of interactions. There's no such thing as "creating a pull request" in git, for example.

It's not at all unreasonable for a user to assume "forking" merely creates a copy with an upstream origin. Read through the steps again:

    1. You fork a public repository
    2. You commit code to your fork
    3. You delete your fork

Note that from a user's point of view, they only committed code to their "copy" of the repository, i.e. their own repository. They never pushed it upstream or created a pull request that references it. That abstraction is clearly wrong if you look at what actually happens but it's not difficult to see why a user might think this way, especially given that "a fork" often simply means "a copy", i.e. something standalone that then goes on to diverge from its origins (e.g. "Edge is a fork of Chromium" or "MariaDB is a fork of MySQL").

Of course the mistake is that the fork is not a copy. The fork isn't a fork (i.e. a separate copy that shares the original's history), it's a view of the original repository with its own refs. The commits are added to the same repository, only the refs that reference them aren't. This makes sense architecturally but it means most metaphors and analogies people likely bring to the table break down because they assume a fork is a copy, not a collection of refs layered over a shared repository of commits - after all "allowing stranges to add commits to the repository" is what PRs are for. Except of course that's not what PRs do then, PRs actually allow strangers to add references to commits to your branches.