You do some blits that turn out to be a no-op - what you write back to memory is the same you read from it: Drop the write cycle. (Needs a cache of some kind. Small one though.)

You do a cookie-cutter, but the mask(or the mask registers) and OR data is 0(a null op anyway): Same effect as above really, but if you can re-order the reads so you skip reading destination you can drop a read and write cycle.
I could imagine this might happen when a bob is word aligned if the code does not do a check for that.

Not sure how much of a win it could be, but I thought it interesting to theorize about.

The cache I mentioned should already be halfway there inside the chip, you only need the A, B, and C data words(depending on active DMA channels) with the matching address they used (16 bits data and no more than 32 bits of address, fitting well into a 64bit int or custom defined size) and do a parallel compare to D/destination; skip cycle if equal.

(My other suggestion needs more logic.)

Should be possible to modify UAE to test this?

There are probably more issues with the line mode at the moment since it is still a bit unclear how it works on a lower level. For example, we suspect (but do not know) that the original blitter line mode made one pair of memory accesses *per pixel* when drawing a line. This, of course, could be improved a lot by a single cache line of memory which is not written out per DMA unless the blitter leaves it. This seems to be a trivial optimization here, and it would then likely speed up line drawing by a factor of probably more than 100 (128 bits per line?) over that of a naive implementation.

But then again this is how i would expand the old hardware without breaking compatibility.