I completely agree with Carmack, but as Tim Sweeney has stated we are gradually moving to a point where the graphics API is irrelevant. As time goes on, more and more of the GPU is exposed to programability and with each release of DirectX and OpenGL (to a lesser extent), the fixed-function pipeline is shrinking. If the trend continues, we will eventually get to the point where everything is abstracted into programs that run on a GPU and buffers... even state management will become a task managed completely by the engine.
If you work on cross-platform console engines, chances are you already wrap the state machine into irrelevance to make up for differences between APIs. Multi-threading is simpler in DirectX, but that is to be expected from an API whose design only requires it to work on a single platform. If you code close to the metal, of course you will see benefits for a specific combination of API / hardware.
OpenGL has traditionally been a monolithic API that tries to maintain legacy support, while accommodating new hardware through extensions. It has a lot of baggage that DirectX does not have, since DirectX routinely drops legacy portions of its API with each major release. Even so, OpenGL comes in multiple flavors now, with the embedded API being much closer to the feature-set modern commodity hardware offers.
Performance wise, Direct3D has held the crown for many years. Portability wise, OpenGL has always been the king. I do not see this changing anytime soon, the two APIs tackle real-time computer graphics from two very different angles. I, like many engine developers, do not have the luxury of committing to a single API, so it is very difficult to effectively exploit the theoretical advantages of either API.