A couple points:
First, I disagree with this detail in Thomas' analysis, and can't quite understand what it claims.
the implementation is free to act as though the method you defined is in fact defined, but completely ignore it when doing dispatch.
Unclear to what this "doing dispatch". print-object is presumably a standard-generic-function, and it is called in normal printing, and how CLOS handles that call is well defined. If user code has defined a print-object method for a user-code-defined standard-class or structure-class, print-object _must_ invoke that method in the usual way. And if that method calls call-next-method, it could well be the case that some implementation-provided method receives control, possibly even a method specialized on class t.
There can be no bypassing of normal CLOS operation for print-object.
What the prohibition on defining methods on system classes means is that user code cannot affect how non-pretty printing handles classes defined in the ANS, which is a larger set than built-in classes. User code also cannot (defmethod print-object ((x standard-object) stm) ...) even though standard-object is not a built-in class.
Unfortunately, the prohibition in the ANS is not quite watertight. The prohibition is oddly based on symbols that name classes and which are exported from the CL package. One could imagine an additional built-in implementation class interposed into the class lattice (perhaps a sub/supertype of character or vector) named by a non-exported symbol. The ANS prohibition technically allows user code to (re)define a print-object method on that symbol, although this clearly violates the spirit and intention of the prohibition.
It makes sense to prohibit changes to how built-in classes are printed, sine in rare cases operation of other modules may depend on printed representation. Suppose #'car works by making a TCP connection to a relational database server that stores the car and cdr of each cons. To make that connection the implementation must be able to depend on the standard printing functions behaving normally. Changes to the several printer special vars can be masked using with-standard-io-syntax, and the current pprint-dispatch table can be lambda bound, but there is no simple or efficient way to shadow print-object methods.
Finally, here is what everyone has been missing about this matter.
A conforming implementation must include CLOS, and must non-pretty write using print-object. But a conforming implementation could include just a single print-object method:
(defmethod print-object (x stm) (write x :stream stm)) ; write presumably contains a big typecase
X3J13 considered CLOS to be important. But existing CLtL1 implementations already had working printers that handled all CLtL1 objects and which obviously did not use CLOS method dispatch. Only minor changes would be necessary to accommodate printing of standard-objects, but to gain acceptance new features were often couched in definitions that imposed the least-possible impact on existing implementations. That's why the requirements for print-object of implementation classes is so loose.