As you would guess from the title of this editorial, I'm in the latter camp, and this document tells you why. The first major problem with capability bits is that they don't represent mutual exclusions. Mutual exclusions arise in situations where a particular device can support several features, but not necessarily at the same time. This is not hypothetical - this is a real problem. Several examples of mutual exclusions exist.
Common ones arise when a single shared pool of memory can be allocated to one of several tasks.
For example, a graphics adapter might have enough memory to support a destination alpha channel or a Z-buffer, but not both. Cap Bits Don't Show Performance Impacts of Enabling Features Capability bits report the existence of features in hardware, but capability bits do not report the deleterious impact on performance that either a single feature or a combination of features can exact. So in the end, while bilinear blending, Z-buffering, alpha blending, and stenciling all may be available, the negative impact on performance may be so huge as to render the combination useless. The obvious solution to this problem is to allow a user to turn certain features on and off at will until the performance reaches a level they find acceptable. To a large degree this can be automated using built in benchmarking scripts that measure performance with different features enabled.