Now, another option is to make gl.viewport and friends take backing store pixels (skipping the CSS pixel compatibility stuff), and to make HD backbuffers opt-in, leaving canvas.width/height alone. This essentially means that the opt-in declares that your program has been adjusted to send backing store pixels (you've made the necessary s/canvas.height/gl.drawingBufferHeight/ adjustments). This means fewer programs will support HD rendering (which, by Canvas's design, is supposed to be implicit), but it's much saner than trying to changing what canvas.height and canvas.width--parts of an API that WebGL doesn't own--mean.
(In that case, most applications would still end up broken in the reduced-backing-store scenario. It's certainly a lower surface-area approach, since it doesn't introduce any new methods or resampling algorithms.)
By the way, that aside I agree there are certain cases where it's
useful to say "don't use a different size backing store unless you
absolutely have to", eg. when using WebGL for image processing or
computation, which will never be displayed in a document. This could be done with either an opt-in or an opt-out.
It's not how Canvas works. If you want Canvas to change, then feel free to propose it on webapps or whatwg. I doubt this will get traction; it would break the use case of laying out <canvas> elements as part of markup. I assume you're not suggesting that canvas.width/height change meaning when canvas.getContext("webgl") is called--that would cause the visible size of the canvas in the document to change (and it'd be very bizarre and inconsistent behavior).