The discoverability argument is somewhat weak because your browser already stores and probably prefills the username.
About not revealing whether an account exists: A site could always reveal a set number of potentially fake handles.
So say a user has two handles registered, and the set number is ten. If the account exists, the two real handles will be in the list, alongside eight fake ones. If the account doesn't exist, all ten handles will be fake, but it's impossible to tell which case you're observing unless you have the key matching one of those handles.
Fake handles are possible, but nobody has attempted it yet that I have heard of.
There is no standard for credential handles (unlike what the article implied), so through heuristics you may be able to get some knowledge of which authenticator created them - and might be able to detect fake ones. You might want to pad both real and faked account lists to have the same number of returned values. These fake handle lists would also need to have some sort of heuristic to them - real accounts can change slowly over time, while fake accounts would be simpler to either always look static, or to regenerate on every call.
The system optionally saving a username is a nice convenience but doesn't really solve any deployment or security problems. Sites would be unable to rely upon that, and it doesn't help with information leakage.
You can save credential information in the client outside a security key and use that to 'upgrade' to discoverability - but you then have that security key only function on certain websites when using that client. You brought your own security enclave but are still platform-bound.
I'll try to explain their argument under the assumption handles were convincingly fake, e.g. there wasn't a heuristic to tell real and fake handles apart.
The underlying protocol (U2F or CTAP) will send all received handles to the separate hardware authenticator. Some of these may be real, some may be fake. Some may have been created by other keys.
There is a process to convert correct handles to a correct private key inside the hardware. This _should_ have some sort of integrity to prevent taking incorrect handles and creating garbage private keys as well - those will fail, but the user experience will be sub-par and there are always cryptographic concerns about processing attacker-chosen data.
So when I make the gesture to authenticate, the valid private key which came from a correct handle is used to sign a response message to the authentication request. All the fake handles and those created by other keys would be ignored.
So if the handles are convincingly fake, the web site would be the only one which would know which were real or fake (so that it can still offer proper user self-service management). An individual piece of hardware would know which were real handles that it created. An attacker wouldn't know if they were all fake.
About not revealing whether an account exists: A site could always reveal a set number of potentially fake handles. So say a user has two handles registered, and the set number is ten. If the account exists, the two real handles will be in the list, alongside eight fake ones. If the account doesn't exist, all ten handles will be fake, but it's impossible to tell which case you're observing unless you have the key matching one of those handles.