I experienced this issue today while cleaning up my keychain. I recently switched from pgp to tofu+pgp trustmodel and this caused me the above error when doing:

Ok the problem really seems to be how parameters are parsed.

All right. It might not be that bad. I messed up with between --armor and -armor but they lead to different results:

Even more weirdness here. So on my test .gnupg directory I just removed the public key of the unwanted recipient.

I went ahead and modified my ~/.gnupg/gpg.conf to use the valid RSA2048 key I want to use for the recipient:

Here is more details. One thing to notice is that the default key mentioned in my config files no longer has valid subkeys since they have all recently expired. I'm in a process of updating them but since I'm only encrypting (and not signing) for a different key I thouhgt it wouldn't be an issue.
I could just delete the offending pub key or clean up my pub keyring but I think it would be good to understand that issue in case there is a weird parsing error.

The problem was an old /tmp/keyring-RT77ms which contained three file: control,
gpg and pkcs11. I think this happened when I had both an Openpgp card and a
PKCS#11 plugged in at the same time. At that time I ran a gpg --card-status and I
could see that two cards were detected but I was not able to access the OpenPGP
one.

Shame on me. I have use_agent in my gpg.conf but don't have the gpg-agent
started. Commenting out this line gave me access to the card again. This is weird
because earlier today I would get a simple warning about missing gpg-agent and
that /tmp/xxx is not available.