I think that the code could make one change to get rid of the additional height array. It just needs to flip the nested loops. Walk along the height field for each vertical line on the screen (2d line walk through the height field image) and keep track of the projected height at each step. Draw only the the difference between the previous projected height and the new projected height if the later is higher.
I was pondering on that solution as well, not entirely sure how cache would behave but in 91 memory was relatively fast compared to CPU so lookup tables were useful still (my thinking is that perspective could be calculated per row if rendering per row but if one would be using lookup tables for that division it wouldn't matter much by flipping to vertical), also if they were running modeX then doing vertical rendering would've been a benefit.
modeX memory layout has a write-enable bit for every 4th (or was it 8th?)column but the addresses was the same so you often would want to write every 4th pixel if doing something "exact" and then change the IO registers so it'd be every 4th again but offset by one, then repeating for offset 2 and 3 and then be done. Unless you were doing flat-shading where this write-enabling could be useful for writing 16 pixels in one 32bit word write with 4 writes enabled (this could also be useful for doing a half-resolution rendering by having 2 offsets enabled and then doing every other column).
(I really loved writing software-rendering code back in those days, glad to be getting much of that power back with shaders these days)
Don't forget, that you have to divide by the z-coordinate and this was also very expensive. With the height field you have to compute one time 1/z or perform a table lookup and then just multiply.
You have to test and optimize both variants to be really sure.
Frankly back in those days even multiply was kinda expensive, i fully expect either of the methods directions to use a combined lookup table for both the perspective divide AND multiplication.
