The backend speaks SMTP, IMAP, and HTTP. It is basically a glue (or proxy) between SMTP/IMAP (including those protocols over TLS) and HTTP. Nylas Pro talks HTTP to the glue (I assume that is using TLS, so HTTPS). Nylas Mail also talks HTTP to the backend, but the backend runs locally, so you're self hosting the backend. I suppose this has a performance loss. (With Nylas Pro, you can set a separate backend server if you desire but that requires work. That is a really cool feature for a business though.)
So I would assume you are hosed. The passwords need to be stored plaintext.
Oauth makes sense that there's no password saved. A unique key is saved which is authenticated with Google. If this key leaks, you are hosed, too, but at least you can revoke that key.
I tried grep mypasswd ~/.nylas-mail/* and grep said Binary file shared.sqlite matches. This did not occur in ~/.nylas it makes sense and it is inevitable, a client like Thunderbird suffers from the same.
It can be circumvented by saving the password encrypted and decrypting it using a master password. That is akin to how LastPass and Mozilla save their cloud data.
Using containers etc would also lower the threat.
In a way its good the password is saved locally. The engine also runs locally. It moves the threat model to the client, away from Nylas servers. Kudos.
So I would assume you are hosed. The passwords need to be stored plaintext.