I imagine that the test for ASCII is cheaper.  It corresponds to the new compact internal unicode representation (one byte characters).

This looks fine.  Can you quantify where the speedup comes from? Reading the code, I see we now maintain a small internal buffer in the file object, rather than using stack allocation at the call sites.  It is unclear to me how this saves memory, since the amount of memory copying should be the same.  Could it be that the speedup is all due to the native 8 bit support for unicode?

Have you looked at providing a special opcode for a few other magic numbers?(We have that in our own custom marshal format)
Some very common values are:
empty tuple
0
1