No it does not. format and type tell the GL how many components of what type of data you are providing. From that, ES decides how to store the data. It may truncate (8 bits to 4 or 5 bits) or enlarge (4 or 5 bits to 8 bits) the component sizes but I think most modern implementations will store them unchanged. In unextended ES 2.0 internalformat is not used. In extended ES 2.0, ES 3.0 and GL, internalformat tells the GL either the number of components (unsized formats) or the number of components and the component size at which to store the texture.
I'm not following your definition of abuse here. The way it works is format/type defines the format you want the browser to convert the image data to. internal_format (and type because it's ES 2.0) defines the format you want the texture stored internally.
In ES if you specified
texImage2D(GL_TEXTURE2D, 0, GL_RGBA, 256, 256, 0, GL_RGBA, GL_FLOAT, data)
where data points to unsigned byte data (which is in effect what
WebGL's OES_texture_float is telling the app to do) then your
application would most likely crash with a segmentation violation;
if it did not the texture would be a complete mess. This is
because the GL would be expecting to read 256*256*16 bytes of
float data but would only be able to read 256*256*4 bytes of byte
GL_UNSIGNED_SHORT_4_4_4_4 and GL_RGBA4 are the same format.
For 2 reasons
1) because ES uses type to decide on the internal format.
internal_format = RGBA + type = GL_UNSIGNED_SHORT_4_4_4_4 = use GL_RGBA4 as the real internal format
It should have been done through internalformat and will likely have to be done that way in WebGL 2.0.
2) because apps can break if they are expecting a certain precision
So, letting the user tell the browser how to massage the data before texImage2D is called lets the user know the exact values of the data. There are tests for this in the conformance tests.
Again it should have been done through the internalformat parameter.
You can't leave it up to the implementation to chose a format based on the content of the image tag. That would leave the developer with no way to update the texture with texSubImage2D nor way way to manually specify mip levels it texImage2D as they'd have no idea what the format of the texture was and if the format/type doesn't match you'd get INVALID_OPERATION then calling texSubImage2D and you'd get an unrendeable texture with texImage2D with incompatible mip levels.
I am not arguing against the functionality only the confusing
misuse of the type parameter.
NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.