TL;DR: At the risk of repeating myself: Google Public DNS is a Domain Name System service, not an ICMP network testing service.
If you want to measure the quality of your DNS service from Google Public DNS, you should use a dnsping tool (https://github.com/farrokhi/dnsdiag [Python] or https://sourceforge.net/projects/dnsping/ [C#]) to send real DNS queries and check for responses. Note that while traceroute -U sends UDP/53 packets, they are not DNS queries, and traceroute -U is not a substitute for dnsping.
If dnsping shows significant levels of unanswered queries (and especially if ping and traceroute do not show any drops), you should check whether your IP address is generating more than 100 queries per second (the default per-IP address QPS limit for Google Public DNS). If you are legitimately generating more than 100 QPS and need to increase your QPS limit, you can request an increase through the Google Public DNS issue tracker.
While Google does not block ICMP or random UDP to 8.8.8.8 or other Google Public DNS IP addresses, there are rate limits on ICMP error replies from Google networking equipment, and ICMP error replies may be de-prioritized within Google networks and could be more likely to be dropped.
There are sometimes network anomalies (I hesitate to call them denial of service attacks, since ICMP is a laughable DoS vector) that send large volumes of ICMP queries to Google IP addresses, exceeding the rather high rate limiting thresholds, and suppressing some ICMP replies. This can cause ICMP-based network monitoring to report "dropped" packets, even when no packets are being dropped (Google is merely choosing not to respond to all ICMP echo requests). For much of the past two weeks ICMP traffic to Google in the DFW area has been affected by such an anomaly.
For this reason, occasional ping and traceroute drops are not evidence by themselves of a problem with your connectivity to Google Public DNS, and do not reflect the quality of service that your DNS queries are receiving. If there is a real networking problem (high latencies or large numbers of drops) traceroute may be useful to diagnose and understand the source or nature of the problem, but evidence of DNS failures is needed to demonstrate the existence of a problem.
Furthermore, if you are having a networking (not DNS-specific) issue with your connection to Google, any DNS engineers you may reach through this forum or the issue tracker are not able to do anything about it (we may forward reports to networking teams in the case of complete connectivity loss causing SERVFAIL for domains, but that is not guaranteed). You should contact the Google networking teams through the ISP portal at isp.google.com or by escalating through your upstream ISP if you do not have a peering or GGC relationship with Google yourself.