I found this behaviour as a result of reading through ThumbnailDatabase::FindFirstPageURLForHost().
It would be easy to limit the output of FindFirstPageURLForHost() to page URLs with the format
".*://" + host_url + "/[^/]*"
using REGEXP but I don't know whether that would be desirable.

I do not know about the specifics of the usage of the FaviconServiceImpl::GetRawFaviconForPageURL() fallback_to_host parameter

I looked into this as a result of someone showing interest of using the fallback_to_host logic for "search engines" in settings. It would be weird for the "Google Flights" icon to show up as the icon for the Google search engine

Assigning to Dominick who introduced the fallback_to_host logic in https://chromium-review.googlesource.com/c/chromium/src/+/846319/

The reason why a visit to google.com/flights results in an All Sites entry for google.com is because certain data (i.e. cookies) is ETLD+1 scoped. As soon as the user visits google.com

For instance, if you replace google.com with some other site that is less well known, you have the following chain in your repro:

1. I visited some site example.com/flights. It shows a favicon and sets a cookie for example.com
2. I go to All Sites, and see an entry for example.com showing the favicon I saw when I visited example.com/flights

This seems like a one-off case given a) how well known the Google favicon is. and b) how often Google hosts sites with different favicons. I think it's more likely than not we'll end up with a good favicon through fallback_to_host than this case.