No, the first two paragraphs are all for running an engine using WB protocol (so Fairy-Max). The two numbers behind them are delay (wall-clock time elapsed between one engine sending its move, and the opponent receiving it), and the second number the average system load on the CPU while the engine was searching (presumably the load caused by the GUI, as I wasn't running anything else during the test).

The 'no GUI' cases do not imply 0 ms delay; there still is a client program that connects to the two engines, and is responsible for passing the moves between them, and perform all other functions usually performed by a GUI. Except that it doesn't display anything of what is going on on the screen. From the data you can see that the display does eat a fair amount of CPU time; the difference between Windows and Linux (i.e. WinBoard and XBoard) is that in Windows this displaying seem to have priority over running the engine, so that it increases the delay. In Linux the engine seems to be always immediately started (i.e. after 1 ms), and the displaying then competes with the engine search for CPU. For the same board size, displaying in Windows seems to take less total time than in Linux, however.