EDIT: Based on your comment, it sounds like your concern might be less "why are these secrets not encrypted?" and more "why is this app storing full Google session tokens instead of using OAuth to get restricted-access tokens?" That is a perfectly valid criticism of the software; it is highly unlikely that it needs more access than it could get through OAuth, and using OAuth is more secure because in the event that the token (or the app itself) gets compromised, it can do less harm to your account and it is easier to tell what happened and close off access.
Just don't expect the access token or refresh token to be stored encrypted, unless the app asks you for a password every time you launch it (and even then, it's possible for a malicious program to steal the tokens anyhow). There are some apps for which the extra security gained from demanding a password on every launch is worth the hassle (password manager apps/extensions like LastPass or encryption tools like
gpg often do this, for example). Unless that's happening, anything else that is done to the secrets is basically obfuscation, not security.
The standard security model for Windows (and other modern general-purpose operating systems) assumes that any code you run is trusted to have whatever privileges you run it with. In other words, if you don't trust a program with access to your saved cookies (and all major browsers store cookies either in plain text or easily decryptable by a running program), then either run it in a sandbox that has limited access to the file system (such as a Windows Store app on Win8+, or the highly-restrictive sandbox Chrome uses for its renderer processes), run it under a different user (standard users cannot read the contents of another user's profile directory, including the AppData directory), or don't run it at all. "Full-trust" (non-sandboxed) apps running under the same user account do not, and cannot, keep secrets from one another; the burden is on the user to not run such full-trust software unless you do, in fact, trust it.
While it might give you some peace of mind if the cookies were encrypted, what encryption key would you use, and where would it be stored? You'd either need to enter a password to generate a key every time you launch the app, or the key would need to be stored in such a way that any other programs running under your account could also access the key and then access the files (there is no such thing as data that only one program could ever read). For that matter, if you run a malicious program under your account, it could simply attach to the Electron app as a debugger and read its secrets straight out of memory.
If you're concerned that somebody running software outside of your account - for example, a privileged process that can read into other users' home directories, or another operating system entirely (such as a thief might use to bypass Windows' protections and try to steal data from your hard disk), you could use encryption to defeat that. Windows offers three main ways to do this: DPAPI (Data Protection API), EFS (Encrypting File System) and BitLocker Full Volume Encryption. DPAPI encrypts or decrypts arbitrary blobs of data with a key that is protected by the user's password; a program must specifically request the data be encrypted or decrypted but doesn't have to supply a key because if the program is running under a logged-in Windows session, the user's key is used (if the program is not running under the user that encrypted the data, this won't work). EFS encrypts specific files (setting it for a directory encrypts all the files within that directory) also using a key protected by your Windows password, but transparently decrypts the data on read (and re-encrypts on write) for processes running under your account. So long as an attacker cannot guess / brute-force your password the data is safe, but malicious software that you run (or that an attacker runs after compromising a program you ran) can still read the data. BitLocker encrypts the entire hard disk (aside from a small bit containing some boot code to enable decrypting the rest) and can be set up to require a password when the computer boots to Windows, but once Windows is running, any software (not just software under your account) will be able to access the disk; BitLocker only protects against offline attacks.
EDIT 2: You mentioned Chrome's encryption of cookies. Chrome uses DPAPI (on Windows), which uses your password as a key protector much like EFS does. On OSX, it uses a password-derived key and stores the password in the Keychain, which I believe is also protected by the user's password (though I may be wrong). On Linux, Chrome apparently uses the static, hardcoded password "peanuts" to derive the encryption key. Security-wise, that last approach is worth exactly "peanuts", so at least the "password" is appropriate. Also added DPAPI to the main response.