Implicit knowledge in your own head about what might or might not be a good idea to program is not the same thing as a specification.  "type(x) is str" is a good specification in this context, while "string subclasses, but only if they're really str" does not.

And the reason why that is, is because the first specification allows server implementers to say, "your type is not str, so you are not conformant; go fix your code."   The second "specification" is just an invitation to (number of server implementations)*(number of string implementations) arguments about what conformance is.

That makes the latter an objectively worse specification than the first, even if EVERYONE would prefer to be able to use their own string type.  Practicality beats purity, and explicit is better than implicit.  These principles are doubly true where interop protocol definitions are concerned.

To put it another way, the greater the social separation between parties, the more explicit and specific a contract between those two parties has to be in order to co-ordinate their actions, because they can't rely on having the same operating assumptions as the other party.  This situation is a terrific example of that principle in action.  ;-)