I'm trying myself to get a handle on the difference in transformation matrices between graphics and text. Other than that, it appears to me that "text" equals all "graphics" capabilities plus a handful of text-specific settings and operations. That would make text a superset of graphics, except for some reason, the coordinate transformations. If you drew a Venn diagram, you would probably see a great deal of overlap between the graphics and text sides, but not one entirely within the other.
Regarding whether save() and restore() should be enabled for "text" objects, that is, the output of 'q' and 'Q' PDF operators, I'm leaning towards doing that (removing the "graphics-only" test). My reasoning is that so much context is passed between graphics and text states. Color, line width, dash, etc. set in text show up in the next graphics object/stream, and vice-versa. It's difficult to control this if only "graphics" can do save and restore, because (keep in mind) all a PDF::API2 graphics object operators are consolidated (in order) into one PDF object/stream. Instead of graphics and text operations being intertwined as you go along, they are strictly separated — and which comes first depends on the order of creation of the graphics and text objects. If you could keep very close tabs on all calls, you might be able to force save() and restore() into the very beginning and end of a graphics object, but it would not be in a very logical order (i.e., hard to understand and easy to screw up).
I think that any call to textobj->save() in use (currently a no-op) would have been put there with the expectation that it would do something. If a programmer realized that it was a no-op, they wouldn't have put it in. Therefore, I don't think that enabling it to work in a text object is going to break any reasonably properly written code. I'm sure there is plenty of code written without understanding of the O-O interactions that I have just documented, complete with lots of "just in case" code, ad hoc settings, and Hail Mary passes, but in any case these ought to be cleaned up.
Some testing:
The following GRAPHICS/TEXT settings are saved and restored:
linewidth(), strokecolor(), fillcolor(), linecap(), linejoin(), miterlimit(), linedash(), flatness() [I think so, but I still can't see any difference between flatness settings, per RT 98539], current transformation matrix, and current clipping port
The following TEXT settings would be saved and restored if save() and restore() were enabled for TEXT:
charspace(), wordspace(), hscale(), lead(), font(), render(), rise()
The following have no PDF::API2 calls and were not tested (most, if not all, can probably be done with ExtGState):
rendering intent (graphics), stroke adjustment, blend mode, soft mask, alpha constant, alpha source, "current color space", "current color" (if different from stroke color and fill color), overprint, overprint mode, black generation, undercolor removal, transfer, halftone, smoothness, text knockout (TEXT setting)