Not even slightly. Encrypted at rest -> who cares where it is stored or how it's synced.
Desktop app: I can stop updating, firewall the app, use offline, airgap a computer, I have many options for reducing my attack surface.
Website: I have literally no way of locking down a version, possible-but-I-haven't-seen-it to be notified of changes (but likely not block them), and it would be rather trivial for the site to ship new JS that simply uploads your password once entered.
Not that I think you are. I assume you'll approach that with the same level of care as you've given your apps (which has been fantastic). But I do think that you're a gigantic payout if someone successfully breaks in. Why should I throw my eggs into such a large, internet-connected basket?
---
For comparison, injecting a malicious update into the apps to do the equivalent of a trivial, invisible JS change means: 1) getting a change into the binary (maybe they brought their own tho), 2) breaking into your app-signing system which is hopefully among your most-secure locations[1], 3) distributing the app to both customers and employees with a visible update notification, and 4) not getting caught before I download it. For each app. Websites are far, far easier to take control of.
[1]: I'm not aware of any server-side security-oriented frontend-web stack which would mitigate this in the slightest. I hope there is though! I'd love to read up on it if anyone knows of one.