Sounds totally untrue to me. The code needs to be very, very fast and efficient to sort all textures, surfaces etc, factor in culling and other cpu intensive calculations.
It depends, but what Gabriel said is pretty much correct.
When comparing two engines with purely graphical demos, the performance usually represents how well the engine handles the rendering of the scene, not how well optimized the CPU code is. You're correct that certain types of occlusion can eat a lot of CPU, but as far as I know neither DarkGDK nor MiniB3D support any type of occlusion, so that's not a factor here.
The main exception to this argument would be if you have a really fast video card, and both demos run really really fast (maybe over 200 FPS). In this case it's likely that the CPU will become the bottleneck and comparing demos this way can show which uses more CPU, but practically this info is absolutely worthless. In fact, if a spinning cube in Engine X runs at 500 FPS and a spinning cube in Engine Y runs at 1000 FPS, Engine X may very well be significantly faster in rendering an actual game environment simply because it
does use more CPU to optimize the GPU's work.
Then finally get down to your game AI and so forth. The CPU can and is stressed by the graphics engine.
Thats a real-world game with levels. If you're going to do 1 room of graphics then sure, the CPU isn't going to be the limiting factor.
Actually, the graphics engine should be the least of your CPU optimization worries. It's things like physics and AI that really consume CPU usage,
not the rendering engine.
I'm not saying that a rendering engine shouldn't be optimized though, just that there's a lot more to rendering engines than CPU usage.
On the topic of DarkGDK / DBPro, I'm surprised to hear that it's faster than MiniB3D. I haven't used MiniB3D myself, but I have made some games with DBPro in the past, and found it to be extremely slow compared to most other engines. I haven't used it a while though, so they must have really improved.