Apart from this case every schema conflict that exists only exists because someone somewhere has modified a schema after creating it, it just requires a bit of discipline. I've seen even Autodesk make the mistake on one of their classification add-ins, so it is easy to do I get that. I made the mistake myself a decade ago when it was first introduced but never since, back then it caused Revit to crash.
Regarding application space vs document space in reality the document is read into memory so is the schema, do they then have exactly the same structure read for every document that uses it? Lastly this isn't managed memory it is unmanaged and the whole technology behind it (OLE structured storage) was written in the mid 90's. It likely works the way it works to an extent because of this, there is only so much they can do to make it safe and 'user-proof' to a managed environment programmer.
One method was removed for 2022
Schema.EraseSchemaAndAllEntities
Now you have
Document.EraseSchemaAndAllEntities
I don't know why the first one was removed they probably realised it was a bit misleading because you can't actually remove entities from ReadOnly documents that exist in the background such as links.
If the schema was owned and given write protection by another add-in you would still have the same access problem with either of those methods. I think purging is likely the only real option because then it is an end user decision but it can only be purged if it isn't used but then if it isn't used why is it in memory? Perhaps it can be purged regardless (used or not used) I haven't really looked at that.
To Autodesk: I also wonder why DataStorage elements are not protected from deletion i.e. is it the case that it doesn't matter what the write access is you can still delete the DataStorage element? People are not going to move away from adding entities to the project information element until the alternative is protected in the same way (or until it is prevented).
