In the ARB's defense, for editing buffer objects there are already sme bind points that are not related to rendering: TEXTURE_BUFFER, COPY_READ_BUFFER and COPY_WRITE_BUFFER.. indeed TEXTURE_BUFFER as a binding point for a buffer object affects NOTHING.
Actually, there are quite a few more binding points that have no semantic component associated with them. All of the indexed targets (GL_TRANSFORM_FEEDBACK_BUFFER, GL_UNIFORM_BUFFER, GL_ATOMIC_COUNTER_BUFFER, etc) have actual binding points in addition to the indexed locations, but because they're indexed targets, these bind points don't have any semantic component associated with them.

Indeed, only about half of the targets actually have explicit semantics: GL_ARRAY_BUFFER, GL_ELEMENT_ARRAY_BUFFER, GL_PIXEL_PACK/UNPACK_BUFFER, and GL_DRAW/DISPATCH_INDIRECT_BUFFER.

But the ARB ain't avoiding DSA. Sampler objects have a DSA API (and they're primarily from AMD, so less of the "NVIDIA trying to push" thing because it's just not true). glProgramUniform is in core. Some form of DSA is getting there, slowly but surely, and not the very same as the GL_EXT_direct_state_access spec, but it's getting there.
"Getting there" would imply progress, the gradual decrease in new features that don't use DSA interfaces. But that's not what we see. There's no gradual decrease in non-DSA interfaces; it's completely random and haphazard. We discussed this: except for new object types, the only OpenGL extensions that are DSA only are those that originated from NVIDIA (like SSO; EXT_SSO didn't require DSA because NVIDIA already implemented glProgramUniformEXT through the DSA extension).

The ARB's policy clearly appears to be not to adopt DSA. But they don't seem willing to make changes to NVIDIA-born extensions just to make them non-DSA.

So I don't see us "getting there" here. New features are just as likely as not to use DSA interfaces.

That is a contradiction. A good API is exactly what OpenGL needs to come close to Direct3D.
Do you honestly believe that the reason OpenGL is not used as often today as D3D is because of its API?

Both had similar capabilities and could hit similar performance, but OpenGL 1.1 helped the programmer to be productive, D3D 3 didn't.
D3D v3 did not have "similar capabilities" at all. It has no software T&L, it had fewer blending modes (granted, so did the hardware, so that was a performance trap of 1.1 at the time), and so forth.

Also, we need to recognize that there is a major difference between how D3D v3's API was terrible and how OpenGL's API is poor. GL's API makes your code a bit inelegant, or requires you to be a little careful. Looking at D3D v3 code is like staring into the Ark of the Covenant. It was bad.

OpenGL's issues are a minor inconvenience.