fria Yup, it's insane.
I think this needs to be a thing AOSP tackles rather than the GOS devs.
Google, for example, have already started blocking apps from reading the values of some user-facing settings by restricting the settings behind private APIs. Additionally, In older API levels, apps used to be able to create unique string that persists after uninstallation and store it in external storage for fingerprinting. This has (mostly) been remedied already by Google with more modern API levels.
It makes sense that the team has not started implementing many anti-fingerprinting measures as there are just too many known and unknown aspects. Fixing a small subset of them does not change the ability of the apps to fingerprint. It would make more sense for the GOS team to implement enhancements such such as making the Android ID
per-app per-profile rather than just per-profile instead of tackling the entire fingerprinting issue.
Overall, I don't think this is an issue that can easily be tackled by the GOS team alone. AOSP is a constantly changing environment so any changes the team makes can become a maintenance burden and AOSP can implement the same functionality later on anyway making the work the GOS team made redundant. As we have seen before as well, Google is already taking steps towards an anti-fingerprinting approach. I think the solution for this problem will just be to wait it out and see what Google does.