This would save memory but add compute cost if the image is drawn to the framebuffer or another sRGB buffer more than once or twice. It wouldn't necessarily be a win to make this behavior the default everywhere.
In the case of web browsers it depends how the image is used. An <img> with a large JPEG is probably drawn only once during tile rasterization, and browsers could certainly use the memory savings, so it would probably be a win. But if you had a small JPEG used as a page background and tiled over the whole screen, the memory savings would be small and you'd be wasting power converting the same pixels from YUV to sRGB over and over, so that would likely be a loss.
That is not necessarily true. In some cases, the compositor maybe configured to sample the input buffer directly from YUV420, applying the transformation on scanout and thereby saving memory bandwidth to read from the framebuffer. This makes a tremendous amount of sense when the source is a video, but much less sense when the source may be rendered vector graphics, which generally look pretty bad with subsampled chroma.
Sure, if you can use a YUV framebuffer then that can save memory bandwidth during scanout (though the conversion to RGB still happens because the screen is not YUV). But that doesn't apply in the tiled page background case I mentioned, as web page contents are composited in RGB.
In the case of web browsers it depends how the image is used. An <img> with a large JPEG is probably drawn only once during tile rasterization, and browsers could certainly use the memory savings, so it would probably be a win. But if you had a small JPEG used as a page background and tiled over the whole screen, the memory savings would be small and you'd be wasting power converting the same pixels from YUV to sRGB over and over, so that would likely be a loss.