That explanation sounds wrong to me. I've written my own implementation of macOS signing logic. TCC doesn't usually tie permission grants to paths, it ties it to the designated requirement of the app bundle, which in turn is usually an indirection through the code signing certificate identity. The whole macOS architecture is designed to let you drag apps around and treat them as files, it's not a UNIX where installation path is meant to matter.

I just dumped my TCC database and the entries are mostly not path tied. The Chrome entry is as expected a bundle ID+designated requirement. Unless the local network permission inexplicably uses a different permissions engine, that statement is a misdiagnosis of what's happening.

     $ sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" "SELECT hex(csreq) FROM access WHERE client = 'com.google.Chrome';" | xxd -r -p | csreq -r /dev/stdin -t

    (identifier "com.google.Chrome" or identifier "com.google.Chrome.beta" or identifier "com.google.Chrome.dev" or identifier "com.google.Chrome.canary") and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = EQHXZ8M8AV

In other words, the permission grant applies to any Chrome channel as long as it's signed by Google's team ID.

Even for chromecast and spotify I never want or use these features, and if I am not turning such a feature on I never want to be asked about a permission related to it, as a user. If I am turning a feature on or I am trying to use chromecast, THAT is the time to prompt me about it

The permission keying off of a temp folder feels so broken. I don't know whether Google / Chrome deserves the blame for the weird hack of running an app from a place the user never specified or Apple the OS for making such a hack necessary and not giving the permission system a way to understand the canonical user installed app as the source of the request.