The reason why browsers have so many CVEs is that they routinely run untrusted code; hence browser developers invest a lot of resources into sandboxing the untrusted code and finding and fixing security holes in the sandbox and all of the native code that is callable from within the sandbox.
For an Electron app, most of these CVEs are probably irrelevant, because the code isn't untrusted in this case as it is bundled with the app already so sandbox escape isn't an issue. (Similar arguments apply to Java with browser plugins vs. "real" applications)
Native toolkits are never used directly from untrusted code; obviously this means they won't have a CVE for sandbox escaping because there isn't a sandbox.
But it also means they have a much smaller incentive to look for security holes in their code. CVEs are security bugs that were found and fixed, and number-of-CVEs is not an indication of how many unfixed security bugs remain. While the attack surface is smaller if you don't run untrusted code, it typically isn't zero, depending on what untrusted inputs a particular application reads. I'd bet that some security relevant UB in a Qt image decoder would take a lot longer to find than a similar bug in a browser's image decoder, simply because of the incentives.
Example, try googling "browser security bounty", then try again with "qt security bounty".
Using electron exposes to some future chrome/Node CVEs and the past ones.
Qt on the other hand is used a lot in emdedd devices/automotive so we can expect security being a top priority of the developers.