Everything you want to do is still possible, but if you want your code to continue to run on the server, you'll need to update your code to work with encrypted files.
You can learn more about the overall design from the "Gory Technical Details" thread:
And over in our open source frameworks, we've published a sample Python script which can decode an encrypted database:
That said, if there's any way to do what you're wanting to do using the OmniFocus local device API rather than reading its database files directly, you'll insulate yourself from file format changes like these. (But I understand that that isn't an option if your code has to run in the cloud, rather than on the user's device where OmniFocus is running.)
I should warn you that encrypting the file format wasn't the only change that we made in this update: we also set the stage for future improvements by changing the data we write based on the capabilities of the registered devices. You can ensure some stability by registering your service as a "older" device, but that will prevent the user from being able to take advantage of new OmniFocus database capabilities as they are implemented going forward. (For example, we're planning to move attachments out of band so that large attachments don't incur such a high cost when compacting the database during a sync.)