I thought it was a joke too. What an awful flag all around:
* Woefully ambiguous and underspecified - what is "major"? A 12 FPS drop compared to desktop? Below 30 FPS? Frame jitter outside a certain standard deviation? It will depend on the app (fast-paced frame-perfect game vs. "well I just want the animation to be smooth" necessarily have different requirements for performance), but this flag leaves it up to the browser to decide.
* Oh, it's meant as a general term for checking whether software acceleration and frame readback (and other yet unknown possible bottlenecks) are engaged, those are the "performance caveats" - but those are either "yes" or "no", there's no way to quantify that with "major", totally meaningless. Unless it's conditionally choosing to succeed even with software rendering if some unspecified performance threshold is met. The 2 sentences of documentation about this flag means I wouldn't know.
* If you Google the name of the flag, near the bottom of the first page you'll find an email thread where someone brought up points like this and was ultimately shot down and the flag pushed through because "the Maps team really needs this." The technical equivalent of legislating from the bench. I wish I could create new browser features to solve all my inconveniences too. Why the Maps team couldn't figure out how to measure the canvas FPS and degrade on their own is a mystery to me.
* To round it all out, the name is also really bad. "failIfMajorPerformanceCaveat" is a weird negative tense - why not "requireUnhinderedPerformance"? That's consistent with the universal standard of "require" (not "failIf", how goofy) and is a lot clearer about the supposed intention of the flag (to try to ensure performance similar to native GL rather than this ambiguous "performance caveats" thing).
Sorry, just a rant about shovelware in the browser stack.