Counterpoint: this is also a big problem with SSH. When a host key changes with SSH you'll get a "Host Key Verification Failure" that basically says "yo, the key I expected for this host wasn't actually presented, you're probably being mitm'd". Then you have to go into your `~/.ssh/known_hosts` and delete a line. Then you get a new TOFU warning that you'll just type "yes" to and proceed.

So most SSH users (who, on average, are way more technically competent than browser users) will automatically 1) panic and think they're being hacked, or 2) blindly trust the new key when a key change occurs with SSH. Both of these responses are dangerous. The result is that, unless you have fancy stuff for managing known hosts for all of your users on all of your endpoints, you're probably just avoiding this scenario by not rotating host keys at all for SSH. Which is also problematic.

By using a CA you're delegating the key binding to a trusted piece of infrastructure that can be locked down and monitored by experts. You can't do that easily with key-bindings written to files on a bunch of different endpoints. With a CA, end users shouldn't need to care about key changes. The fact that the CA can issue a new certificate for some entity is a benefit: it makes credential rotation easier. If you do want to know when credentials rotate there are ways to monitor that yourself (and Web PKI has ways like key pinning and cert transparency).