I'm a little confused if you mean designing a HD game, as in for 1080p, in which case you just set your viewport to 1920x1080 and off you go. So I'm guessing you really mean high-DPI graphics so designing for different display DPIs (aka the device pixel ratio, or number of physical pixels to CSS pixels, e.g. 2 for 2x retina devices).
The intent in C2 is just to design it all at the highest resolution, and let letterbox scale shrink it down where appropriate. There are so many device pixel ratios out there (including 1.325, 1.33, 1.5, 1.7, 1.8, 2.37, 2.4...) that designing artwork for each level is insane, and even if you do 1x, 2x and 3x, there's always going to be a bunch of devices scaling that anyway, so it seems you may as well go with the highest and let the GPU scale it down.
Mipmapping improves the downscaling quality and performance. It uses a slower, high-quality downscaling filter at initialisation time to take in to account all the image's pixels. It basically turns the image in to an array of images at sizes 1, 1/2, 1/4, 1/8... down to 1px big. Then if the image is half as big it renders from the 1/2 size image. If mipmapping is not used it just linear samples down the full-size image, which requires more GPU bandwidth since it's sampling a larger area of pixels, and the quality is inferior because linear sampling only ever considers a 4x4 patch of pixels at the sampling point, which is insufficient for more than 50% downscaled images. Beyond that it skips areas of the image which causes aliasing artefacts that make it look "crisp". Some people subjectively seem to prefer that look, but it really is actually technically worse quality.
It is a bit of a problem that WebGL currently does not support mipmaps on non-power-of-two images. This means in preview mode often you won't see the effect of mipmaps, regardless of your "downscaling quality" setting. However after export, most images are assembled on to power-of-two spritesheets and then mipmapping can take effect. I can see this inconsistency is frustrating, but it is fixed in WebGL 2 (which can mipmap any size image), and in-editor spritesheeting is a goal of C3 which would help preview work identically to export.
So anyway if we can assume for a moment that mipmapping is enabled, then with all artwork at full resolution, the GPU is basically rendering from high-quality automatically downscaled source textures by using the appropriate mip levels. This should resolve any question about performance. It does use more memory on devices which don't need the extra detail. On the up side if you zoom in or upscale images then you get the extra detail back. Perhaps there could be a feature to save memory in this case. However with good game design and C2's existing layout-by-layout memory management, this already seems largely mitigated (I don't hear much about it). Also you probably need to optimise the full-resolution version of your game anyway, since corner-cutting device vendors will happily stick an insanely high-resolution display on a weak device with not much memory, so the memory use of the full-res version is still a concern.
I do think there are some features we could add to make this easier though - in particular I think if the image editor had a way for you to tell it what the device pixel ratio of the source image is, it could get the default size in the layout view correct, and improve the detail of tiled backgrounds, etc.