Eh, that's debatable. Could be confirmation bias because we're just used to it being that way for the last x decades. Fairly sure that if I asked my computer illiterate grandma which made more sense, google.com or com.google, the answer would be "neither." Heck, my parents only add www or com simply "because". There's no rational reason from their perspective to do so other than that it may not work otherwise. If I had originally taught them com.google vs google.com, they'd be none the wiser (assuming either way actually worked).
I actually suspect if we started with a clean slate, it would make more sense to start with "more generic/less detail" to "less generic/more detail." Urls after the domain already do that (well, organized sites, do), e.g. www.site.com/cleaningsupplies/clorox
Then we could have (expanded for example):
company.google
organization.charitynavigator
uk.company.google
xxx.whoa (for those that remember the proposal for a xxx tld)
But there's probably a technical reason for it being the way it is that I'm not aware of or something.
Er... to me, if I really stop and think hard about it, none of these make sense. If I really wanted it to make sense, I'd just type "Google", "RBC", "BBC" - the brand name and it would figure out the rest for me. If the site was secure, my browser would figure that out and tell me it was secure. If the site wasn't secure, it would figure that out too and warn me as such.
Of course, I realize that this is a tall ask given that you have conflicting brands around the world. Perhaps there should be some linguistically obvious [to the average non-I.T. person] way to differentiate between conflicting brands...
I feel like the most obvious should be that we should never have to negotiate security by typing HTTPS... that should be the default state, falling back to HTTP only if HTTPS was unavailable and a warning should be given to the user. The average user [indeed any user] should never have to "look for HTTPS" or "look for the padlock". The whole browser UI should be more intuitive than that - the user should be able to look at the browser window and infer that communication with that site is not secure.
I'm not sure what the address structure should be... perhaps something like(?)
- CA/CHURCH/UNITED/SASKATOON [Localized Home Page]
Perhaps a global brand such as Amazon or Facebook wouldn't even need a country code...or it could be figured out by an algorithm based on the user's context: FACEBOOK
could map to UK/COMPANY/FACEBOOK for a person in the UK or US/COMPANY/FACEBOOK for a person in the U.S. The user could override the location by manually typing the address. If the user's IP address belonged to Amazon in the US, then they could type in just the site and resource address and the rest of the address could be construed from their context: Typing in STORE/ELECTRONICS/DVD/LORD-OF-THE-RINGS would automatically be understood as: US/COMPANY/AMAZON/STORE/ELECTRONICS/DVD/LORD-OF-THE-RINGS. For a residential user, their IP would be assigned to the block for their country, so any sites not explicitly specified would infer a site within their own country.
If the country code isn't known, then some algorithm could attempt to figure it out. If it was ambiguous, then the user could be presented with search results by a preconfigured [or their favorite] search engine.
Anyway - as Tim Berners Lee says... it's too late now. Until someone sets about re-imagining the entire infrastructure that is today's internet, we're stuck with what we've got.
I actually suspect if we started with a clean slate, it would make more sense to start with "more generic/less detail" to "less generic/more detail." Urls after the domain already do that (well, organized sites, do), e.g. www.site.com/cleaningsupplies/clorox
Then we could have (expanded for example): company.google organization.charitynavigator uk.company.google xxx.whoa (for those that remember the proposal for a xxx tld)
But there's probably a technical reason for it being the way it is that I'm not aware of or something.