Based on @SD0001's comment on the Core patch, I'm now convinced that this is actually already ensured, with only a slight change in the patch I linked.

The important bit for that conclusion is that UserOptionsLookup::getOptions( $user, EXCLUDE_DEFAULTS ) returns all $user's options that do not match the current site wide defaults (disregarding any conditional defaults). Because ResourceLoader::getUserDefaults also disregards conditional defaults, the logic behind mw.user.options should treat the case the same way as if the user themselves changed the user option to the conditional default.

As far as I understand it now, with the current patch, mw.user.options would return the correct values for conditionally default options. It'd still have some limitations (mainly the inability to see conditional defaults definitions), but I think that's perfectly acceptable (and if someone ends up needing that on the frontend, we can easily add it in the future).

I verified those assumptions with the following configuration and with no manual overrides of foo-opt:

$wgDefaultUserOptions['foo-opt'] = 'before';
$wgConditionalUserOptions['foo-opt'] = [
        [
                'after',
                [ CUDCOND_AFTER, '20230624000000' ],
        ],
];

For a legacy user, mw.user.options.get('foo-opt') returns before (as expected) and for a freshly registered user, mw.user.options.get('foo-opt') returns after (as expected).

With this in mind, I think we can close this task as Resolved. @Tgr, @SD0001 or others, if you disagree, please feel free to re-open with your thoughts.