Additional Information and Corrections:
* The enemies aren't always active, or at least most of them aren't. What's actually happening is that the game chooses the initial walking direction for most enemies based on pseudo-random numbers when (re-)starting the level.
* The timing for the screen update code is extremely speed sensitive. To the best of my knowledge, version 1.4 is lacking any kind of forced delay between updating the display starting address and drawing to the video memory. The game uses double buffering and this quirk means that the game tells the video card to swap the buffers and then proceeds to draw to the buffer of which the game thinks it's no longer being displayed while the video card is actually still displaying that buffer. I think that having no delay at this point might have been a good choice for most of the systems back in 1991. The game usually has other things to do in between updating the display start address and drawing new things to the back buffer, like collision detection and such, so the CPU cycles were better spent doing that rather than just waiting. But that only applies to a rather narrow range of CPU speeds, unfortunaltely.
Anyway, I created a patch for Keen 4-6 that fixes this problem and as far as I can tell works perfectly in DOSBox as well as on all "real" DOS PCs I could get my hands on. I think the only configuration where this code doesn't work correctly would be DOSBox set to EGA with a dynamic core and maximum cycles. VGA and SVGA will still work fine with a dynamic core and max cycles, but such speeds tend to break the game's AdLib dectection, so I wouldn't recommend that combination of core and cycles settings anyway.