(Not sure how I missed this issue.)

The spec identifies how a module should be loaded (or how it was loaded and should be reloaded).  We should be careful to preserve that identify and not invite uses to modify the spec after (or while) the module is loaded.  PEP 451 talks about the difference a little, but I'm pretty sure it came up in more detail in discussions about the PEP at that time.

IIRC, originally PEP 451 made ModuleSpec immutable and there was a mutable version of it for use by finders that had a mechanism to "freeze" it.  (We dialed that back because it was mostly unnecessary extra complexity.)

As to the module attrs, I agree about which are unnecessary and which must stay (__name__, __file__, __path__).  __name__ and spec.name don't always match (e.g. for __main__).  Likewise for __file__ and spec.origin (e.g. frozen stdlib modules).

Regarding __path__, it is the only attr that has an impact on import behavior (other than reload) after the module is loaded, e.g. when finding submodules.  As noted, users sometimes modify it to affect that behavior. 
 We want the spec to preserve the information used when the module was loaded, so __path__ and how it's used by the import machinery should stay the same.

FWIW, I've also seen cases where __loader__ is overwritten to facilitate different reload behavior, but don't remember if I've seen that lately (and don't remember offhand if that even worked after PEP 451).  Regardless, I'm not convinced some other solution wouldn't be better to address that use case if needed (e.g. add "reload_loader" to ModuleSpec with this use case in mind).