Sorry about this!
I was using a SQL trace to debug this, and it looks like there's another set of deletes in the same call chain that leverages Adapter.DeleteEntitiesDirectly (passing the primary key fields in a range compare predicate). When I looked through the trace I thought the direct delete was generated by the code in step 2, but it was unrelated.
It also had nothing to do with LLBLGen pro. It turns out another table (with many records) contained a foreign key to the parent table, and that foreign key wasn't indexed, which hurt delete performance.
Thanks!