If you know you have stopped incs, then delete, then start again (with some external synchronization) then deleting is fine.
Actually, fyi, I don't think that's true because there is no guarantee that subsequent update will end up being ultimately merged (by compaction) in the order they were received by the replica. You could even theoretically have the case where it looks like everything worked properly (i.e. you get only post-delete stuff accounted for) for a while, and then a compaction ends up compacting the pre and post increment but not the delete and pouf you get a corrupted value.
Which btw is not to say that using milliseconds for counter timestamps was on purpose, it's definitively an oversight that has persisted somehow. But we had discussed the idea of making the current behaviour more "official" by making counter deletes use Integer.MAX_VALUE. The rational being, if you try to increment-delete-increment, if the post-increment don't work, you might be surprised initially, but at least it makes it clear that something doesn't work. If doing an increment-delete-increment kind-of works in simple testing, it's easy to miss the fact that counter deletes are broken and to get bitten later on. Given that even with external synchronization you can't really guarantee that increment post-delete will work as said above, I'm tempted to go with the more clearly-broken-so-you-don-t-get-bitten-badly-later behaviour.