Re-reading your original post you mention that you never want to replicate DELETEs on this particular set of tables. Assuming this means NO replication, PERIOD (eg, you're not also replicating in a warm standby config), I'd probably opt for disabling the replication in the PDB (ie, why incur the overhead of processing by the repagent and repserver to process txns you don't want to replicate?).
To disable replication of the DELETEs you can wrap the DELETEs in a pair of 'set replication off/on' commands. While the repagent will still scan the records it won't actually send them to the repserver, which in turn means no overhead for the repserver to process the DELETEs (regardless of whether you use a no-op function string or dsi_command_convert).
A downside to this method ... everyone writing code that performs these particular DELETEs will need to know to use the 'set replication off/on' wrapper. If you can route most (all?) of your DELETEs through a small number of stored procs then it makes it easier to manage the placement of the 'set replication off/on' wrappers. And obviously you'll want to document this type of activity so future developers/maintainers know about the use of 'set replication off/on'.
And just in case someone forgets to disable a DELETE in the PDB, you could still use the no-op function string or dsi_command_covert as an extra precaution to insure the DELETEs do not end up in the RDB.
Obviously (?) the use of 'set replication off/on' should not be considered if your DELETEs need to be replicated to other RDBs besides the history database.