The Google AMP Cache serves files up to 12 MB in size via HTTP/2 by default. Even though AMP is not bound to the use on mobile devices, they are the main motivation behind AMP.
I've just read a paper about the performance of HTTP/2 on cellular networks. While they found that HTTP/2 is faster than HTTP/1.1 for small files (2 MB), they also saw that package loss for files that are 8 MB or larger has a higher impact on HTTP/2 than HTTP/1.1, resulting in higher page load times (i.e. HTTP/1.1 is faster than HTTP/2 in this case). In their research 32% of all mobile connections experienced package loss.
Therefore I've been wondering if HTTP/2 really is the way to go for the (Google) AMP Cache.
HTTP/2 has consistency been shown to be faster for most sites. Are there certain scenarios where its is worse - absolutely! - but should you hold back improving most sites for the minority? No in my opinion.
However, even with that, I think there are other factors you also need to take into account:
AMP pages are designed to be more performance and I would say that, especially for them, 8mb pages should be the exception not the norm. So while it may be more efficient to use HTTP/1.1 for larger pages in certain scenarios - it is more efficient for most smaller pages to use HTTP/2.
Should you fall back to HTTP/1.1 for larger pages? Perhaps, but that is more complicated as the protocol is negotiated first before you know the page and downgrading would necessitate a redirect or similar and definitely slow the page down.
Should AMP and the AMP caches restrict to 8Mb rather than 12Mb given they use HTTP/2 and this paper suggests that might be a better limit? Perhaps - but then again it's not like they won't work on HTTP/2, they will fall back gracefully but may not load as fast as if they were on HTTP/1.1.
Also most of the AMP pages themselves should be small, and progressively load non-essential assets (e.g. images or videos). So a large file (which is likely to be an image or a video) may not block the critical rendering of an AMP page anyway even if there is packet loss.
Are all mobile pages loaded over mobile networks? Do any people use mobiles over WiFi networks were package loss should be less (I know I do!). The paper is unclear whether the 32% figure is cellular connections (i.e. not over WiFi) or all mobile connections (i.e. cellular and WiFi)
Google also is experimenting with QUIC underlying HTTP/2 rather than TCP - which addresses the main reason for slowness over the single HTTP/2 connection (that is that a single TCP packet loss will hold up all HTTP/2 streams, and not just the stream that packet belongs too). Granted this only works in Chrome right now so other browser will not benefit from it yet, but again Chrome has a sizable user base.
So based on all that, I think HTTP/2 is definitely the way to go - and especially for AMP pages. As I said in the beginning it's not perfect, and there are some pages which might be slower over it in certain conditions, but the vast majority of pages should be faster over it and therefore it should be used.