I would have expected the following specifications for String.prototype.matchAll and RegExp.prototype [ @@matchAll ]:

String.prototype.matchAll ( regexp )

1. Let O be ? RequireObjectCoercible(this value).
2. If regexp is neither undefined nor null, then
   1. Let matcher be ? GetMethod(regexp, @@matchall).
   2. If matcher is not undefined, then
      1. Return ? Call(matcher, regexp, « O »).
3. Let S be ? ToString(O).
4. Let R be ? RegExpCreate(regexp, "g").
5. Return ! CreateRegExpStringIterator(R, S, true, false).

RegExp.prototype [ @@matchall ] ( string )

1. Let R be the this value.
2. If Type(R) is not Object, throw a TypeError exception.
3. Let S be ? ToString(string).
4. Let C be ? SpeciesConstructor(R, %RegExp%).
5. Let matcher be ? Construct(C, « R »).
6. Let global be ? ToBoolean(? Get(matcher, "global")).
7. Let fullUnicode be ? ToBoolean(? Get(matcher, "unicode").
8. Let lastIndex be ? ToLength(? Get(R, "lastIndex")).
9. Perform ? Set(matcher, "lastIndex", lastIndex, true).
10. Return ! CreateRegExpStringIterator(matcher, S, global, fullUnicode).

String.prototype.matchAll:

• Directly testing for @@matchAll avoids the extra IsRegExp call which can produce side-effects. And it also matches the calling pattern in all other String.prototype methods which take a RegExp argument.
• For the non-RegExp case: Calling RegExpCreate to create a new RegExp object and then calling MatchAllIterator to create just another new RegExp seems wasteful and makes it harder to optimize this function for implementors.

RegExp.prototype [ @@matchall ]:

• Similar to the case from above, avoiding the extra IsRegExp call makes it easier to optimize this case, because we don't have to worry about potential side-effects.
• Calling the RegExp constructor without an explicit flags argument allows us to take the fast path in 21.2.3.1, step 4 (https://tc39.github.io/ecma262/#sec-regexp-pattern-flags).