Intent is that a person who saves a file using a proper transform doesn't end up with the proper file.

That's a bug, no?

I think currently this behavior only applies to byte type formats (ie EXR half-float unaffected)

EXRs are designed to encode any type of data, which may include but is not limited to:

• scene linear colour data
• display linear colour data
• scene nonlinear colour data, typically via a log-like transform
• display nonlinear colour date
• linear or nonlinear non-colour data such as depth, normals, cryptomattes, alpha occlusion, etc.

So while you are correct that the _current_ behaviour is for byte encoded data, it would also technically impact EXRs based on the colour space input setting, as the saving of EXRs is based on the in-reference memory state.

For the colour data components, proper transform chains are required for all, even when saving from one already linearized format to another.

In terms of a design, a simple stack of transforms would suffice, with a “default” set via preferences. The preferences would be set by default based on OCIO default roles, and overridden where the audience has set a specific default.

a pixel pusher with the correct view set for an Apple Display P3 Display, ends up baking in the Display P3 transform into file encodes

For display referred file formats, it's the right strategy. While for exrs, blender as the image producer, should write the gamut metadata(I assume blender already did this since a patch some time ago).
As a recommandation: for the display referred file formats like jpg and pngs, blender should write a "srgb.icc" or "p3.icc" into the image file, since if not, a external composite software would have no clue the image's gamut.