Sorry, we don't see any need for ed448. There's nothing wrong with the algorithm per se, but there doesn't seem to be much point for it. Being able to break ed25519 seems to require either a fundamental cryptanalytic result against elliptic curve cryptography or quantum computation.

In either case, the attack that allows ed25519 to be broken is likely to apply equally to ed448. I.e. if one falls, then the other is almost certainly going to as well.

Quite an odd decision. ed448 differs from ed25519 same as rsa4096 from rsa8192. It's not about quantum computation resistance but about a key length. Moreover ed448 is included into multiple RFCs and supported in openssl for example.

I believe this decision should be reviewed.

openssl supports Ed448
gnupg will support Ed448: https://dev.gnupg.org/D505
erlang ssh supports Ed448: https://erlang.org/doc/man/SSH_app.html

For completeness it should be noted that since this bug was closed, ssh-ed448 was formalized in RFC 8709:

https://tools.ietf.org/rfc/rfc8709.txt

Adding more and more software that supports Ed448 may look a bit spammy, but I cannot resist doing exactly that:
 
Putty supports Ed448 keys since v0.75 (released 2021-05-08)
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ed448.html

Thanks for re-considering :-)