Archiving data from logging db (high writes, no reads)
The problem is that these deletes are now taking over 10 hours to run.


if you are not on Enterprise edition - as Partitioning - switching in and out is only supported in Enterprise edition, I would suggest you to create and ordered view on the top of table that you are deleting data from. This will incur less I/O and generate minimal T-Log.

Founded the link written by SQL CAT team about  Fast ordered delete technique of using a view or a CTE.

e.g. 

-- tested to delete 27 million and it took 24 mins to delete

CREATE VIEW vw_TABLE_TO_DELETE
as 
select top (100000) * from TABLE_TO_DELETE
where CONDITION
ORDER BY LogTime 

----  Caution : perform actual deletes now !!
--- start an Explicit transaction to avoid Log flushes.

BEGIN TRANSACTION

DELETE
FROM vw_TABLE_TO_DELETE

---- if FULL Recovery then do T-log backup
---- if SIMPLE Recovery then perform a CHECKPOINT

COMMIT TRANSACTION  --- in case if we want to cancel in between, the deletes are committed in the log already



  Should the logging db be in snapshot isolation mode?


You have to test it out depending on your workload. Read committed Snapshot isolation (RCSI) has a tempdb overhead as it has to do a lot of row-versoning. The Database engine will store a version of the previously committed image of the row in tempdb.

ON a highlevel - RCSI - selects do not lock data during a read operation and Read transactions do not block write transactions and vice versa.