A Z-buffer requires a lot of memory space and, as a brute force algorithm, would have been expensive given both the given bandwidth of the ISA BUS to the graphics card and the memory restrictions.
Which is why most old DOS games probably first reduced the number of polygons with some clever algorithms (BPS tree, raycasting, depth sort, etc.).
But were there any games that didn't do that and implemented a Z-buffer in software?

My thoughts on this would be:
I guess because the graphics cards were practically just pure output devices and couldn't do anything themselves and the ISA bus had a significant bandwidth limit, the Z buffer would have been stored in the system RAM and only then would the finished rendered image be pushed into the VRAM. Or would Mode-X or Mode-Y have benefited here, apart from the fact that it would have allowed double buffering?
With the help of DOS extenders and protected mode, enough memory for a frame buffer and a 16 Bit Z buffer in the system RAM could have been allocated.

But were the CPUs of that time, I was thinking in particular of a 486DX with 33 MHz, fast enough for this or did this require at least a Pentium with over 100 MHz or even 200 MHz?
Branches would have been expensive if the 486's 5-stage pipeline had to be flushed. Parallel processing of several pixels at the same time would not have been possible either. So you would have had to calculate all 320x200 pixels one after the other or at least severely limit the viewport window.

Has a software Z-buffer solution been implemented in any DOS games and if so, which one(s) were they?