As I understand it, GetFTR is not a user facing tool. A user won't have any control over whether there are GFTR links in the tool they are using any more than they control any other aspects of what an interface presents to them. From what I read, any discovery layer (what GFTR is calling a technology integration partner) will eventually be able to turn on GFTR links using the APIs. So, beyond Dimensions, Mendeley, etc. in the early pilot, GFTR links could eventually appear in Google Scholar (if Google wanted them to), in library subscribed databases (beyond Dimensions), in A&I services, in citation management tools, on ResearchGate, etc.
The issue of aggregator content and GFTR is not whether the aggregators might turn on GFTR links (which they may) but that aggregator hosted content is currently not able to be a target for a GFTR link. So, if the library doesn't have the content from the publisher directly, the GFTR link will convey to the user that the library does not have it ... even if it does on an aggregator. Some of us suspect that while libraries will see this as a flaw in GFTR, the publishers will see this as a feature and so this "limitation" (to use Roger's term in the SK post) is likely to persist.