This is an idea that people keep coming up with that seems cool in theory but in practice doesn't really work.
Ignoring the question about security compared to a normal password manager, the biggest practical issues are
1) Once you need to handle password changes and special password requirements (length/containing or not containing symbols), you end up having a list of exceptions that's similar to a password vault anyway (once you're synchronizing an encryption key and list of exceptions you might as well just use a vault-based password manager like Pass)
2) You can't see what sites you have "stored" passwords for (since there are no stored passwords). This means it can be hard to determine whether you have an account on a given site, and if your key is compromised you may not be able to determine all the sites you need to change the passwords for.
3) The password is also tied to the domain, so without a list of stored passwords it can be extremely confusing if a company switches domains without you realizing it or remembering what the previous domain was. Ideally this shouldn't happen a lot but it's not as infrequent as you would think among companies that have multiple brands if they change their sso system or something. (I guess this would also break fido so maybe companies will stop doing it if fido really catches on.)
4) You can't store information other than passwords. This is really annoying on sites where you have to create usernames if you don't/can't use the same username everywhere. You can put this information in the exception file from 1 but the more information you put there the less point there is in using a "vaultless" password manager.
I did actually use a vaultless password manager for a period in the past, but based on that experience I concluded that the downsides hugely outweigh any advantages and would not recommend that anyone use them.
Yes, I wrote a tool for myself a few years back to do this, but abandoned it. 1 was especially problematic for me. To add to your list
5) You have a problem if you need to cycle a password for a site either due to some password rotating policy of theirs, or a security breach requiring a reset.
The config file about password requirements and password cycle number could be more semi-public, it's not a secret but you'd probably not have it on github either (no reason to let people know where you have accounts at; still, it's not a secret).
It also doesn’t seem to know about usernames. How do you create multiple passwords for a single domain? Does using something like username@domain.tld for the realm work?
In addition to these I also find, personally, that having multiple different accounts on the same domain is pretty common. If you go to the subdomain/FQDN level, it might be less common, but then you have the problems that (a) companies change their login subdomain even more often and (b)
With a vault, I can choose whether I want the URL to be matched to the base domain/public suffix, to the host/subdomain, to the whole path, etc., for each entry. And in fact I do have pretty much every option my manager (Bitwarden) offers in use (except maybe "regular expression"). Without a vault, you have to remember which option you chose, which means you effectively have to use the same method for every site (or at least for most sites, whatever you don't log in to often enough to remember).
It also causes problems for those companies which have "SSO" by using the same credentials across multiple different subsidiaries/affiliates on different domains - I'm thinking here about United Healthcare, who have sign-in at `healthsafe-id.com` for insurance, and at `healthsafeid.optumbank.com` for FSA, using the same set of credentials (and yes, obviously this is a terrible practice on their part, but you often don't have any real choice about using companies with these terrible practices).
And it also makes any integration/automation (i.e. at its most basic "press a hotkey to inject password keystrokes for the current selection") need, as you mention, a list of exceptions/mappings (or else to not work for any sites like these).
Ignoring the question about security compared to a normal password manager, the biggest practical issues are
1) Once you need to handle password changes and special password requirements (length/containing or not containing symbols), you end up having a list of exceptions that's similar to a password vault anyway (once you're synchronizing an encryption key and list of exceptions you might as well just use a vault-based password manager like Pass)
2) You can't see what sites you have "stored" passwords for (since there are no stored passwords). This means it can be hard to determine whether you have an account on a given site, and if your key is compromised you may not be able to determine all the sites you need to change the passwords for.
3) The password is also tied to the domain, so without a list of stored passwords it can be extremely confusing if a company switches domains without you realizing it or remembering what the previous domain was. Ideally this shouldn't happen a lot but it's not as infrequent as you would think among companies that have multiple brands if they change their sso system or something. (I guess this would also break fido so maybe companies will stop doing it if fido really catches on.)
4) You can't store information other than passwords. This is really annoying on sites where you have to create usernames if you don't/can't use the same username everywhere. You can put this information in the exception file from 1 but the more information you put there the less point there is in using a "vaultless" password manager.
I did actually use a vaultless password manager for a period in the past, but based on that experience I concluded that the downsides hugely outweigh any advantages and would not recommend that anyone use them.