I'm aware how package signing works. What does any of that have to do with my comment?

Step 3 is a reason people publish their keys to keyservers.

Step 3 is reason for people to publish signing keys, not encryption keys. That was the whole point of my original comment.

Let's follow a tutorial for GPG (I'll take the Arch one since I've already discussed, but many are similar): https://wiki.archlinux.org/title/GnuPG#Usage

So here's an interface for key creation in gpg

    $ gpg --full-gen-key
    gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Please select what kind of key you want:
        (1) RSA and RSA
        (2) DSA and Elgamal
        (3) DSA (sign only)
        (4) RSA (sign only)
        (9) ECC (sign and encrypt) *default*
        (10) ECC (sign only)
        (14) Existing key from card

There's also --quick-gen-key which doesn't show this info.

Now put yourself in the boots of a new user: Why would you pick to have a key with less features? Maybe the user thinks they may want to encrypt something in the future. Not to mention, many people did this process years ago, and forgot what they picked.

Then you publish that key with gpg send-keys or the keys.openpgp.org web interface, possibly at a later date, then you just pick the one key ID that you have.

And now you have a key published for signing and encryption, with no intention to use GPG email.

That's irrelevant. The act of publishing has a well-established meaning. Publishing an encryption key, only to shame others who have used your key to send you encrypted data is unreasonable. How is that different from publishing a book and shaming your readers for reading it? "Oh I didn't know that by publishing a book, I was encouraging others to read it!" isn't a good response.

Also, any user of a tool should at least check what the primary purposes of that tool are.