Using the MMU (040/060) during C2P is not a problem but it's not actually meant to be a very good way of doing it from what I've read in developer forums.
Unfortunately most demoscene coders avoid using it but it's quite useful when just parts of graphics move. IMHO for 3D FPS games it's not as useful (well, you may save some bandwitch and cpu time if you stop moving but since 99% of time the user is moving at least the camera it's almost useless)
I'm surprised that you get such good performance from using Shapeshifter as it is emulating a Mac and running in 640x480 8 bit using AGA. In my C2P tests AGA runs like a dead-dog in 640x480 8 bit
PAL HiRes Laced is fast, at least it doesn't slow down chipram access. The problem is that you move 4 times the quantity of pixels so you eat at least 4 times the bandwitch. That's the reason MMU is very useful when screen resolution increases: you need to gain some bandwitch and MMU helps to move less pixels.
so I'm not sure how Shapeshifter does it, maybe using the MMU to redraw only part of the screen is the answer for doing fast 640x480.
that's exactly what Fusion/Shapeshifter do. And in games with little scroll it's definitely very useful. I think that some SCUMM games would take advantage of that (specially on 030)
Moreover: If you ever needed to use pseudo truecolour modes for 2D stuff you should really need use the MMU because chipram bandwitch is chocked and you need to move too much data.
I'll have to do some tests and see what kind of performance I can get out of C2P in AGA using the MMU to do partial updates.
For 2D games it should really help. I think that the optimal approach to speed up scumm would be modifying it to compose the screen in planar mode directly, if the complexity of the scene increases compose parts of the display in fastram. I guess it would be quite a lot faster than using chunky for everything although I haven't seen SCUMM code. For me it's clear that scumm is not exactly optimized: games that ran perfectly on A500&286 shouldn't need as many resources.
It looks like Duke Nukem does use the FPU which would explain why it it would be slow slow on anything but an 060. Swapping to fixed-point maths would obviously help but I guess it would still be way too much for an 030 (the original requirements are for a 486DX2/66!).
Duke Nukem ran without problems with 486/33 and ISA VGA. 030s may be weak but it should be playable on 030 reducing screen size/detail.
I like developing WB friendly games, bypassing the OS is not the way it's done these days 
Fast AGA graphics and System Friendly usually does not match well. You could be writting to chipram at 7MB/s speed but if you leave the OS alive you lose precious performance. BTW, using Paula instead of AHI also speeds up sound parts. Since the core of the games doesn't require multitasking it would be possible to write code that shuts down the system when AGA is being used but allows multitasking if RTG is being used. It should just require some changes in the init part when AGA is detected and in the rendering part (so AGA code performs c2p or fast2chip memcopy when copper interrupt dictates it. Leaving the OS alive would be bad because you couldn't write to chipram at 7MB/s in that small and short period of time). The only downside I can think is killing the chance of network games.
Maybe Cosmos could modify graphics.library so WPA and chipmem-writing operations accumulate in fastram and only copy data to chipmem when display is finished and before next frame begins :-D
