...I believe there is a fundamental reason why WebGL can not use an sRGB
color space by default, which is that OpenGL ES 2.0 does not have any
sRGB support, not even in the form of an extension. (EXT_texture_sRGB
exists on desktop hardware.) As I understand it, the way that most
WebGL implementations would support an sRGB color space for the back
buffer would be to use an sRGB texture as the color attachment for the
FBO they use behind the scenes. If this is correct, then it will be
impossible to make WebGL use an sRGB color space on mobile hardware.
Since a major motivating factor of the WebGL specification has been to
provide a uniform API and behavior between desktop and mobile
hardware, I do not think this is a viable option at the present time.
So it sounds like you are advocating that all textures go into WebGL in physically linear color space. If so, we would still need your original flag to avoid conversion into that linear space so we can send pixels in unchanged. If we did that, the conversion from sRGB (which many images will be in) to linear will lose precision and cause banding in the dark areas. But if an author wanted to avoid that, he could turn off the conversion and do it using the pow() function in the shader, right?
No, if the output is 8-bit linear, it is impossible to avoid banding
near black, regardless of what your fragment shader does. The reason
is that the codes for the various dark colors you need all map between
0 and 1 (in a range of 0..255) in linear space. If the output were
12-bit linear (or better), you would be able to express the necessary
dark colors, and you would not experience banding.