> The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.
That's not quite right. Yes, on older graphics cards the texture size is padded to a power of two. But they are not forced squared. So, in your example, the 400x1 pixel line would become a 512x1 texture.
For older graphics cards, 32x64, 128x8, 16x1024 are all valid formats that won't be padded, but taken as is. (Just a few examples)
Modern graphics cards don't have any of these restrictions anymore. They deal with non-power-of-two textures natively, and graphic languages like OpenGL (which WebGL is based on) also support NPOT textures. WebGL's only limitation is that mipmapping and wrapping is not supported for NPOT textures. (See https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support)
This is all true, except not in the case of Construct 2.
Construct 2 will export your sprites to fit into the smallest power of 2 spritesheet that gets loaded into memory as a texture.
There is also no usage of compressed texture so that even large black areas take up the memory budget. I understand the constraints, mobile hardware differ greatly, thus the base needs to be covered.
Until it changes, devs need to be careful not to underestimate how much memory is actually used even for simple sprites and thus with any large project intended for mobiles, this needs to be taken into account during game design. Making a PC game offers a lot more freedom due to most PCs having 2gb vram, and many systems that use integrated GPUs like Intel HD3000/4000 etc, have a lot more due to using system ram as vram.