At this point most operating systems are ahead of Electron on average, not behind it. Electron takes longer to bundle a new Chrome version than it should. Then it takes a while for applications to actually upgrade Electron versions because that includes the compatibility headaches of keeping up with all of Chrome changes, Node changes, and Electron API changes at the same time. Some apps are years behind on Electron today simply because they don't want the headache of rebuilding Node native dependencies or fixing Electron API breaks and think being on an old build of Chrome and the subsequent risk of unpatched security problems is an okay risk to take.

There is still a long tail of versions you might encounter when using a (security supported OS), but for most Linux distros, macOS, and Windows the worst case in the long tail is now just 6 months behind. (You lose security support if you don't keep up with semiannual OS releases.) If you have reason such as a corporate overlord to also support LTS OSes the worst case is closer to 2 years depending on Unix distro. (Windows WebView2 remembers IE and still requires regular update cadence even on LTS Windows, so WebView2 on today's LTS Windows should still be closer to the 6 month mark than the 2 year mark if following Microsoft's LTS policies, staying within support, and not paying for more complicated LTS contracts.)

It should be very easy with caniuse/MDN statistics to write web apps for any browser of the last six months. If you plan to support macOS you still need to support two (related like siblings) renderers as macOS wants you to use WebKit/Safari and everything else is Chromium in one way or another today, but testing on two browsers shouldn't be a showstopper for many (most?) apps. There are definitely Chrome-only APIs that might appeal to you in building an app, but at that point many of them you can polyfill with a native dependency (a Rust dependency in the Tauri world).