All options are loaded at pageload, because they include not only plugin/theme options, but also WP native stuff, like menus and widgets. Distinguishing between which ones to (not) load based on whether they are needed would take quite some calculations, so the performance issue you refer to doesn’t exist.
Now about the extensibility. Let’s take a look at the WordPress action sequence. One of the first hooks you see is plugins_loaded. Any decent plugin would only initialize later, using the init hook. So, for extensibility you could hook into plugins_loaded to make sure your filter is in place before any call to get_option.
In the rare case where a plugin would simply start executing at load time, you would need your extension plugin to be loaded first. As you say you could write a must use plugin for this. Or you could edit the option table to make sure your plugin is the first in the queue (yes, the list of plugins is also an option).
Now, finally, to your question: is this desirable? The fact that there are five different filters in the get_option function certainly suggests so. However, if you are a plugin developer, would you like others to mess with your options without the user noticing? I’d say, if a plugin developer is explicitly not using the best practice of hooking his plugin options, maybe he simply does not want anybody to mess with those and you should respect that.