The game does something a bit odd when calculating the delay factor used later by the delay loop. INT 21h/AH=25h is called to hook INT 24h, and the offset of the handler in the DX register happens to be 39Eh, which is then used as an IO port to read from during the delay factor calculation. AFAICT, 39Eh is an unused port, and the calculation loop reads it 12,330 times while also reading the BIOS timer ticks; so perhaps some kind of IO delay would have an effect. However, it may not be the most important issue.
The message delay loop itself calls a subroutine that calls INT 21h/AH=06h/DL=FFh to read from STDIN, allowing a key press to immediately exit the loop. I have encountered other games that incorporate the code overhead of DOS functions into their timing; and because DOSBox has very little overhead for its internal callbacks, the timing can be perceptibly off. I made a TSR program that adds a 300 cycle delay to all INT 21h calls, and with it the game's message delay is just about right; and the 0-9 delay factor selectable in-game also has a noticeable effect on the delay. Note that I haven't actually counted how many instructions real DOS executes for the function in question, so 300 is just a number I've used with good results on other games that use other functions.