Except a good software renderer like WARP or LLVMpipe can run that kind of scene at more than playable FPS.

At this stage I really really regret even mentioning the word "Quake" here as my doing so seems to have steered this thread down a completely irrelevant path. What I meant was a Quake-like level of scene complexity, as in low-polycount, low-resolution textures, low screen resolution (maxing out at perhaps 640x480 or 800x600), no complex effects, etc.
...
So taking these two together, that's the kind of scenario where a software OpenGL implementation will get you below 1fps even with the low level of scene complexity I mention. Yes, even on a modern CPU. Anybody want a citation? OK, see for example this thread where the OP in it got 0.5fps owing to using an OpenGL feature that was supported by the driver but not in hardware.

It all depends on what features you want.

I know you regret bringing up quake, but it is actually a good example. They released two versions, one using their custom rasterizer and another using the OpenGL rasterizer. IIRC they released the source for both. Just a hunch, but I'm fairly confident if you ran GLQuake with Mesa software drivers you'd probably still see a highly performant game on today's hardare.

The specific post you mentioned was fairly high polygons using a blending function. Neither of those fits the quake-style graphics which were low polygon and simple texturing.

Naturally if you are trying to run something complex in a software renderer, such as your collection of modern shaders or even a moderately complex blending function, then yes you are quickly going to get bogged down.

The first question was "what does this mean?" which I think was fully answered.

The second question was "is this possible?" which is a little more complex. It is certainly possible to make a fast 3D opengl game with a software renderer if you limit yourself to a subset of the features. It is also possible to make a 3D opengl game with a software renderer that takes hours per frame.

The OP was about OpenGL design. OpenGL is about rendering generally, and the design reflects that. Games represent a subset of what OpenGL does.

Except a good software renderer like WARP or LLVMpipe can run that kind of scene at more than playable FPS.

Thanks for the examples. I was not aware that WARP even exists. It is really great, BUT it is a substitution in the cases when there is no GPU in the system, or drivers don't support 3D acceleration on such GPUs. As a substitution, it enables rendering, but it is at least an order of magnitude slower (which is excellent result) than there is a GPU. Usually it is almost two orders of magnitude. Anybody could easily experience that through 3DMark tests.

The first question was "what does this mean?" which I think was fully answered.

The second question was "is this possible?" which is a little more complex. It is certainly possible to make a fast 3D opengl game with a software renderer if you limit yourself to a subset of the features. It is also possible to make a 3D opengl game with a software renderer that takes hours per frame.

The OP was about OpenGL design. OpenGL is about rendering generally, and the design reflects that. Games represent a subset of what OpenGL does.

I completely agree that it is possible to do everything on the CPU side, but it is not a wise decision. OP has a very naive question, and I hope he had a better insight now. I'm glad that there are some efficient CPU based implementations, but they should be used only when any other alternative is impossible. Probably every low-end GPU can easily outperform the fastest commercial CPU, leaving it free to do other tasks.