Here's my take on the issue-- similarly to how the ViewRep setup works, it would be nice to offer lockability of LODs for the following reason: When a LOD is created, it may be only partway through design of a complex system, but is only ever intended to load a specific group of components (for memory management purposes). Hence, if there are more parts/components added to the assembly model AFTER the fact, those parts are then added to all created LODs (since they cannot currently be locked).
The problem is this -- There is no current solution to prevent changes to existing LODs. Suppressing the link to the Base Component is only a temporary solution to this, as IV requires a model update once the link is unsuppressed BEFORE being able to edit the included components from the Derived reference (and thus, automatically loads any unwanted new components/parts). Breaking the link permanently disables further updates from being captured by the model containing a Derived reference, so this is not a solution.
The only way direct way around this is to maintain each individual LOD (in the Derived reference) by periodically suppressing new components. Depending on quantity of components present, this can represent exponentially longer model update times, and unnecessary model maintenance, as the parts need to be loaded/unloaded for each LOD, upon activation. This is also an unsatisfactory solution, as this would need to be done EACH time a new component is added to the Derived reference, or whenever the model containing the reference is intended to be updated. This may or may not even be possible if one is working within a multi-user environment using a Vault implementation, due to the required assembly file potentially being checked out by another user (this frequently is the case in a small company working on big projects).
Obviously this affects productivity, directly, since it extends the amount of time required for each operation. The best current indirect workaround (to me, anyway) is to copy a locked, maintained ViewRep to a LOD of matching name (using the Copy ViewRep to LOD function, and containing only the parts intended to be present in a purpose-driven LOD). However, this, while simpler to implement, would still need to be done (each time) before updating a model containing a Derived reference. In order to avoid naming issues, it would also have to be done AFTER ensuring the previous LOD (the one intended to be updated) is deleted from the LOD list. I imagine that a Macro or an iLogic rule could be created to automate this operation (though I haven't tried to do so).
A caveat to my above workaround -- though this should work for Drawings (but you shouldn't be using LODs to manage drawing views anyway, that's what ViewReps are for!), I have not tested it against Derived references, and don't yet have evidence it won't screw up the part loading/unloading in a model containing a Derived reference, due to the deletion of the previous referenced LOD.
So, to wrap it up, PLEASE PLEASE PLEASE add the ability to lock a LOD to Inventor!
Also, I don't know if it belongs as part of this request, but another nice functionality would be for ViewReps and LODs to be "linkable" through an explicit operation. What I mean is this -- if a ViewRep is copied to a LOD (or the inverse), a context-menu option becomes available (via right-click) to associate the two representations (could be as simple as only being available if the names match) and any updates to component states within either one. Selecting this option would maintain a visibility/suppression state link between the two -- see my hypothetical example below:
1. Create ViewRep [named view], w/only desired components shown
2. Right click ViewRep, select "Copy to Level of Detail"
3. Mini dialog box pops up with a checkbox "Link Representations", add check to checkbox, click "OK"
4. New LOD (with matching name to its base ViewRep) is created, and a chain-link icon is visible next to both representation names, to indicate that they are Linked Representations.
5. Effect a visibility/suppression state change in either representation, and update model. At this point, any components that have had EITHER a suppression or visibility change, or both, reflect these changes in both representations, without any additional maintenance necessary.
6. Any models/drawings that reference these Representations (appropriately) should then update without having to redefine any relevant design intent.
***I may edit this if I notice typos or decide to change wording around for clarification.***