When people talk about SSH CA's, they're talking about systems where you are granted access to a fleet of servers not by having your id_rsa.pub copied into a bunch of authorized_keys files through some automated process, but rather by having the whole fleet trust a CA key, and then having the CA key sign certificates for users (typically: through an identity provider). The wins are:

* It's a lot easier to provision users because the per-server configuration is static.

* You can issue short-lived keys for users so that a lost laptop won't be carrying lots of dangerous SSH keys.

* You can force users through your standard authentication flow and get things like MFA without requiring the SSH servers to understand MFA individually.

Outside of this use case, it's not common to sign SSH keys at all. SSHFP isn't widely used; in fact, almost nobody uses it (because almost nobody uses DNSSEC in the first place). But even if you were set up to use it, SSHFP wouldn't do the things we're talking about when we talk about SSH CAs. In fact, it'd be hard to come up with a worse place to put user keys than in the DNS, which is public, even (in fact: especially) with DNSSEC.

Yeah, I've done it for users, but it's basically the same for host keys; you sign the host key with the CA, stick `HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub` in your sshd config, and stop getting prompted to manually verify host keys on connection. Would that not still be called a CA?