I wouldn't worry about a) too much, as you've already counted them, most sites are "one time use", and those that aren't usually have some interactive or time-sensitive feature that requires short (if any) ttl on any caches not under the site's control. d) is true, but also is somewhat under the site's control and should provide numbers.
Most people use GA for a rough picture of "how many people visit my site?", and stats from any CDN will most likely be enough for that. And browser caching doesn't really concern those people, because most visitors aren't returning visitors.
There is a high correlation between a usage pattern being interesting and likelihood of it making a representative appearance in the logs.
Understanding usage patterns shouldn't depend on knowing absolute numbers. Assuming "dumb" content is cached relatively uniformly, the usage patterns itself should be sufficiently inferable from the logs. For the non-dumb content, why would consumption of highly dynamic endpoints have distortive cache utilization at all?
To add more, how often high-resolution usage data really translates into actual product improvement? What percentage of sites have that much traffic to justify engineering hours spent on micro-growth-hacking based on this level of data?
If the system is designed well, in a lot of cases the users won't be receiving the resource from your server, they will be receiving it from a) their browser cache, b) their local network cache, c) their ISP's cache, or d) a CDN. Your server logs might be showing several thousand hits while the number of times a page is actually shown to somebody might be tens of thousands of hits.
Server logs are great for logging what is happening on your server, but awful for understanding your user base.