And hey, user security is a pretty good reason to encrypt a database, but if security were the only aim, they could have made the data accessible for export purposes (after all, it's accessible for the user to read).
At this point in history I'm not even sure it's worth going into all of the reasons this is a terrible thing to do on their part. At best, they'll scare off some users from migrating away briefly and buy themselves some time to figure out what they need to do to produce something that's better than the competition they're attempting thwart. More likely, they'll simply fail (quickly or slowly). It's that last point that really matters to me. If I'm buying an application that I'm going to rely on, I want comfort that the company will continue to maintain the product -- or in the case of open-source, confidence that the product is still regularly maintained (or in languages/frameworks that make it practical for me to maintain myself).
Aside from the fact that I wouldn't want that feature 'as it has been designed, today', I wouldn't want to rely on a product that's being designed by individuals who aren't well versed in the perils that DRM-like behavior causes. After all, that's what this is -- it's an attempt to keep the user from transforming their own data for the purposes of locking that customer into the product while attempting to position the lock-in as a security feature. And it failed on both accounts, Zotero worked around the encryption (which means the bad guys can to) and if people looking for a product like this care about that capability, they'll likely refine it to the point that it's as capable encrypted as it is decrypted.
Every time I've been asked to implement a DRM solution I've either outright refused or paired it down so much that the "R" didn't really exist. They're horribly complex to write, off the shelf solutions are already cracked and time would be better spent giving customers something they're willing to pay for. The thing that makes me roll my eyes every time I read one of these is "there are still engineers out there who think this is a good idea?"
I can't wrap my head around what causes this kind of thinking -- it's not a zero-sum game, there's room for more than one product in the marketplace -- even if one of them is free and open-source. Trying to beat the competition by sabotage rather than by making a better product doesn't work ... at least not for very long.
[0] And they also do my least favorite "other marketing thing" -- "Create a Free Account" and no hint of what the thing costs in any obvious place. So maybe this other product is free? I doubt it -- Like most companies, I'm assuming they're perfectly happy collecting your personal information for free (in order to send marketing to you to get you to pay for whatever service is tied to the free account). It's the little deceptive things that drive me crazy -- you didn't trick me, you only managed to make me suspicious of your product.
[1] I've gotten lucky ... usually budget and time doesn't allow for wasting energy on customer-hostile features that won't achieve the ends they're aiming for. The only case where something "DRM-like" was in an application I wrote was to be the opposite of customer-hostile. We had an app that provided information to users based on their permissions, determined by them logging in. I pushed to make the automation (sending us the login information) opt-in, with manual provisioning options. It worked well, since if they failed to true up after months of warnings, the application would deactivate (due to the size of the customers, months of warning was somewhere near a year and could also be disabled with a flag).