The dictionary page for *print-readably* says
Individual *methods http://franz.com/support/documentation/current/ansicl/glossary/m.htm#method* for *print-object* http://franz.com/support/documentation/current/ansicl/dictentr/print-ob.htm, including user-defined *methods http://franz.com/support/documentation/current/ansicl/glossary/m.htm#method*, are responsible for implementing these requirements.
so the implementation's applicable print-object method for class condition violates this requirement.
The explanation of *print-readably* unwritten in the ANS is that it's purpose is to provide a guarantee that something written will later be rereadable without error, producing an object that is the "same" as the original. (The definition of "same" is a different Lisp execution complicated, but not the central focus here.) Mostly *print-readably* guarantees that the emitted sequence of character can be reread without signalling error.
All this depends on a bunch of other assumptions, and the necessary details are incomplete in the ANS. Here are just some of the issues:
What about *print-pretty* and dispatches defined in the current pprint-dispatch? If there is some such dispatch that would violate rereadability, should the printer ignore that *print-pretty* is true? A naive reading of the standard suggests this is a requirement (despite being operationally ridiculous) but perhaps the intention was that *print-readably* ought just bind *print-pretty* false. But if so, the ANS would have said so.
What about other printer variables? One might define a print-object method that assumes that *print-base* will be the same at reread time -- but the ANS doesn't say this.
Perhaps the ANS missed requiring that *print-readably* can assume the emitted sexpr will be reread inside a with-standard-io-syntax? But the ANS doesn't say this.
What about the package system? Whether the printed representation of a symbol has zero, one, or two colons depends on the current state of the package system. Should *print-readably* assume the package system will be the same at read time? Perhaps, but the ANS doesn't say this. And with-standard-io-syntax doesn't help with this.
There are a great many more potential issues. We must conclude that *print-readably* is only a hook for user code to provide a _weak_ guarantee that no _other_ user code will do things that prevent printed output from being rereadable without likely notification at write time. But to achieve even this weak guarantee, user code must cooperate with what it knows about the printer and reader. That it applies to the printer representation of conditions might protect a mostly-numeric output file from containing an unreadable #<floating-point-underflow> object where a float is expected.