You hadn’t included how had you arrived at this concept, but the whole “presets” branch of logic is pretty strange.

Post-filtering vs pre-filtering

WordPress filters are de-facto centered on filtering results. Your my_plugin_get_options filter follows that model — the results are produced and offered for modification.

Sometimes that is undesirable, what if we do all that processing just to throw result away? The fallacy is to pre–filter and affect results before they are produced. Which looks somewhat like what you are trying to do with my_plugin_get_presets. Usually this ends in unholy fragile mess. Even core uses this in few places with same underwhelming results.

Defaults

You don’t need to retrieve and process defaults on every access.

When plugin activates if settings are empty save defaults as settings. The only thing left to handle what if set of defaults changes, on top of my head you can probably check and add missing defaults on save.

Cut everything away

So you get rid of defaults and of presets — you end up with very little code (which is a good thing). You just retrieve your saved options and filter them. Every plugin who needs to do whatever with options can use that filter perfectly fine.

That leaves out making fields read only. In my opinion that could be just different filter altogether. There might be a need to filter options without making them read only and other way around. They don’t have to be coupled.