OK, now I'm sitting in front of the front end of a computer rather than the back end of a smelly wet large long-haired dog.
The restriction on "portable programs" extending (redefining, whatever) MOP functions is here:The motivation for this particular restriction is twofold.First, the CL language implementation as well as the MOP itself may depend upon the MOP itself. The intention is that the language and MOP can use CLOS and even the MOP in their own implementation, and if they do, and use only "specified" classes or classes specified on class (and operator) names in private packages or otherwise unexported and unknown to properly-written portable programs, those programs won't break the implementation or affect the efficiency of its implementation. This is no different than the ANS prohibition against redefining cons to take its arguments in reverse order, expecting that if the portable user application code was written against this specification, the result would be harmless. But global definitions Lisp worlds are indeed global (*).The second reason is less obvious. The implementation of ANS CL, CLOS, and the MOP obviously all depend upon themselves. Thus their implementations are metacircular and need protection. Furthermore, the full MOP protocol even where not metaciculr is expensive. If it must be obeyed for "specified" operators on objects of "specified" classes, execution efficiency may be unacceptable. The CLOS and MOP subcommittee of X3J13 IMO did an exquisite job making it possible to implement these subspecifications into a usable "industrial-strength language."The CLOS subcommittee recommended that CLOS, but not MOP, be accepted into the standard, because the MOP had never yet been fully implemented, and was not yet ready for standardization. That is exactly what we (X3J13) voted.