In the modern day that's arguably fine, most users only interact with a few actual companies online (though many of them haphazardly use dozens of domains and dozens of unrelated certificates).

The only 'real' problem though with this approach is it requires a trusted path for the bank to get the "JP Morgan Chase root CA cert" into my hands (like a QR code they hand me physically). Serving it up over http: or over an unvalidated SSL context at first use seems to defeat the purpose since I could be being MitMd the first time I hit chase.com. In practice most people would be angry that they couldn't use the bank's website if their new phone or PC didn't have the certificate yet, and if places start advertising their cert QRs everywhere, it will normalize the idea that you add a CA certs all the time, leading to CA cert QRs being on billboards and bus stops and eventually fraudulent ones would be snuck in that way.

Yes to smaller scopes, with keys passed of during interactions that organically arise, preferably face to face, but maybe not always. No to making domain names be the thing that's being trusted.

We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.

So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.

Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.

This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.