enterprise geodatabase - Prevent row deletion in versioned tables using database privileges

I have versioned tables in an Oracle geodatabase (versioned with the option to move edits to base).

I would like to prevent users from deleting rows from the tables when using ArcGIS Desktop.

(With that said, the users still need to be able to select, update, and insert rows into the tables.)

The reason for preventing the deletion of rows is:

The asset records in the tables need to be preserved/decommissioned so that they can be integrated to a work order management system. We cannot allow rows to be deleted from the GIS, because the GIS records would become out-of-sync with the records in the work order management system (in which deletes are not possible, and historical records are preserved).

---

ArcGIS functionality:

It is my understanding that preventing deletes is possible with out-of-the-box ArcGIS functionality on unversioned tables:

Grant and revoke dataset privileges:

If the dataset is not registered as versioned, you can grant and revoke the update, insert, and delete privileges individually using the Privileges dialog box. For example, you can grant a user select and update privileges, which allows the user to connect to the dataset and alter existing features but does not allow the user to add new features or delete existing features.

If the dataset is registered as versioned, the privileges that allow a user to modify a dataset (update, insert, and delete) must be granted and revoked as a group.

---

Question:

I understand that preventing deletes is not possible on versioned tables using out-of-the-box functionality in ArcGIS.

However, is there a reason why I shouldn't prevent deletes via database privileges?

REVOKE DELETE ON ROADS FROM ROLE_EDITORS_GROUP_A

Answer

I tested REVOKE DELETE ON ROADS FROM ROLE_EDITORS_GROUP_A in ArcGIS Desktop 10.3.

It failed; when trying to INSERT a new record with DELETE revoked, I get this error:

Unable to save edits. Underlying DBMS error [ORA-01031: insufficient privileges].

Explanation: (adapted from @Vince's comment)

ArcObjects is testing for all of the privileges (SELECT, INSERT, UPDATE, DELETE) before doing anything, even though DELETE isn't required for INSERT: