Probably it is possible to have some sort of delay for these changes, and after some time values will smoothly become game controlled again if the plugin will not update them again.
Or it can be possible to get default values calculated by the game and operate them on plugin side
Getting the default values is a bit tricky, because that's solely calculated client-side atm... so reading these values from the client require a callback, which is a bit cumbersome to use but also has some overhead (especially when reading this frequently)...
Having some delay for the changes is probably better, but that also requires the plugin to override the values frequently (resulting in some overhead again due to the sync packets that need to be sent to the client)...
Not sure if it's maybe sufficient to have a way to set a relative value instead. E.g. a color the fog gets multiplied with. So if the player goes into a cave (which makes the fog darker automatically), that would also affect the color set by the plugin. In addition to the "multiply" mode, we could also add an "additive" or "overwrite" mode to add or overwrite the color (maybe with a "weighting" parameter to control how much it should overwrite the game values) 
Or alternatively we may use a concept similar to Unitys HDRP volumes: We may add a similar object to the API where you could overwrite fog data, lighting, colors etc, then you could set a weighting for this volume and a priority. Such a volume could be either local (defined by an Area), or global (then the priority and weighting controls how much your settings should overwrite the default values of the game) 
Probably it can be a custom function that will look for LOD component in GameObject and if it found one will change it or put into internal list to control later (for example when setting are changed). If the function will be not called the LOD will stay same as in prefab, and when called it will be synchronized with the game
Oh, basically you could add an LOD component already, it should at least work with the LOD bias graphics setting. But unlike vanilla elements, it does not get culled if out of view bounds...
Maybe we could add a setting where you could determine if the game object should be always visible or bound to the view distance (or detail view distance) 
That's good, so we will be able to override built-in definitions, but what about completely custom? Like new types of wether or objects?
You will also be able to create new definitions that way
However, for custom items, there is some additional information required (to handle animations etc properly).
Looks like events will be more compatible with each other, while custom module should be a bit faster. If the system will have events then different plugins can apply their own changes to world separately: for example one plugin can alter cave generation and another one can change ocean. If this will be done in modules they should be somehow connected with each other and "know" about changes done by other plugins, otherwise there will be only one plugin that can change world in the pack
Custom world gen modules would be indeed faster, but may be also a bit trickier to use (especially if there are multiple plugins which register their world gen modules). In case of events, that wouldn't be a big issue at all, because if multiple plugins listen for that event, they will automatically see changes done by other plugins (depending on the execution order of plugins).
We have to think about that. Actually we have already done some preparations for a "GenerateWorldPartEvent" some time ago (basically it's in the API, but it's not exposed and not fully functional yet). It's called everytime a new "world part" (which is basically a world section with a size of 512x512 blocks, i.e. 16x16 chunks) is generated. A plugin could use this event to load custom heightmaps, for example, or overwrite terrain materials or plants etc 