The criticism of AMP I keep seeing is that "because it uses weird HTML, it must be proprietary and designed for lock-in". But because WebComponents allow you to extend HTML by introducing new elements, it's actually completely standards compliant in HTML5.
Based on the parent comment's criticism that it's designed for "lock-in" (without any elaboration), that's the argument I was addressing.
Google, and solely Google, control what tags are allowed on AMP pages, and thus what advertising and analytics companies are allowed to compete on AMP sites. AMP also requires that every page depends on external JavaScript sourced from Google, which can explicitly change without notice, and thus can't be audited and locked via SRI hashes.
These points of centralization and control are antithetical to the premise of the Web as an open, inter-operable, democratic medium.
You could also serve the JS from your own domain if you prefer. Similar to Google's cache, it's something available as an option to you.
Regarding the Amp standard, that is indeed something controlled by Google. Particularly as it pertains to the SERPs. But because it's open you also have the option to fork it, or write a completely different implementation if you desire.
If you'd like to modify Amp but still stay within their standard, you can submit a PR as well. It looks like about 75% of PRs are merged.
> "AMP is an evergreen JavaScript library. We will not allow users to lock themselves into a particular release."
Which completely precludes using SRI.
Further, pages serving their own copy of the JavaScript "won't be considered valid AMP," and thus would be ineligible for the placement benefits afforded to AMP pages in Google results.
AMP's governance is not similar to HTML's. Changes to HTML require consensus between mutually competing browsers, while AMP is a single-vendor land-grab. That consolidation of power threatens to return us to the dark ages of Microsoft's sole dominance of the de facto Web.
Based on the parent comment's criticism that it's designed for "lock-in" (without any elaboration), that's the argument I was addressing.