Look, we have been though this before, in 1994, 1995, 1996, 1997, etc.
Sprint (1239) used to filter based on AS_PATH. They stopped after FLIX incident.
The list in radb is :
whois -h whois.radb.net '!oMAINT-AS15169' | grep ^route | awk '{print $2}' | grep -v "::" | wc -l
6180
I picked four prefixes. 3 were in RADB. 1 was not.
What is preventing you from crafting your import policies based on this data? Google is clearly creating route objects for most of their prefixes and rejecting a handful of prefixes vs. the risk of accepting at worst a full table seems like a reasonable tradeoff. This is something Verizon could have done, and something other folks like Level3 have done for some time.
2) When asked "Are you using RADB/Altdb entries to filter routes/should we use those?" being told "No".
If Google used that basic hygiene then it would not be announcing routes it does transit.
We have also had this debate when smd proxy aggregated routes because certain network was announcing every /24s instead of /12s causing certain routers to run out of memory ( I'm pretty sure those were AGS+ ). It came known as "you will aggregate or I will aggregate it for you and you won't like it". While it was done just for a few hours the consequences were rather unforeseen.
Right around that time it was determined that no one outside the AS knows why the AS is choosing to announce routes in a specific way and those outside it were better not be "smart" over it. That was also around the time it was decided that one simply registered everything correctly and announced only what was registered and announced it the way it was registered.