I did some research, and I think I now know where the problem lies.
The Bug
While I obviously don’t have the original source code for Obsidian, I played with the development tools and the transpiled JavaScript code, and it would seem that Obsidian indeed uses the same method as the System Dark Mode plugin; specifically, it calls window.matchMedia() to get a MediaQueryList, to which it attaches an event listener for the prefers-color-scheme media feature, with a callback to a function that sets the theme depending on if the value is dark or not. Now, this would normally be all fine and dandy, except that the prefers-color-scheme feature has been broken on Chromium on Linux since 2019, specifically in the way that it does not react to the selected GTK theme – which is what GNOME and Fedora (among other Linux distributions and desktop environments) use. Since Obsidian is dependent on Electron, and Electron is dependent on Chromium, the bug also affects Obsidian.
The Fix
But wait – how does VS Code, which is also written in TypeScript and Electron, get around this on Linux? Their theme service uses Electron’s nativeTheme module, which provides an API to read and react to the system’s theme changes. It presents a general interface while performing the actual system-specific theme logic under the hood so that Electron users don’t have to do all the OS-specific handling themselves. Because of the previously mentioned Chromium bug, Electron developers have implemented a workaround for GTK themes for the module. The workaround seems like a good solution for now since Chromium developers don’t seem to be in any hurry to resolve the issue on their side.
There is still one noteworthy thing to mention. Starting from version 42 – released a few months ago – GNOME now uses the FreeDesktop settings portal for providing the user’s dark style preference for applications, which can be set by the user in GNOME Settings. Electron’s nativeTheme module does not support reading this value yet, which means that GNOME 42 users (like yoavzack and kalcifer above) cannot currently rely on that system setting for Electron applications. As a workaround, they could use this GNOME extension, which supports scheduling dark/light theme changes (I’m using it on Fedora 35; it works great). The extension changes the actual selected GTK theme, which Electron’s current workaround relies on. The dark/light preference in GNOME Settings won’t change the selected theme; instead the selected theme (Adwaita by default) simply adapts to the chosen preference if it supports it.
In Short
The solution for Obsidian would be to use Electron’s nativeTheme module instead of using prefers-color-scheme directly. This would instantly fix the issue for most Linux distros that use GTK themes, and hopefully soon for those on GNOME 42 or other very recent desktop environment version that implements the FreeDesktop settings portal. However, even the cutting-edge users will be able to benefit from the nativeModule change right now before Electron fixes their GTK integration by using the extension workaround mentioned above.