Compressing to ETC2 only to convert to uncompressed means you save no space in graphics memory and take an unnecessary hit in visual quality. Re-compressing to another compressed format means you loose even more quality.
Well, basically what I'd like to do is compress all of my assets using a lossy codec similar to JPEG for distribution. During installation I would like to find out what texture formats are actually supported by the hardware (the ones that will give the best performance and quality) and then do a one time conversion
Erm... you've just gone lossy -> lossy with your JPEG -> "whatever" conversion, frankly an extra decompression step isn't going to damage your quality anyway as you stuffed it with the first conversion to JPEG.
In short; your idea here combines basically the worst of everything. There is a reason the data path tends to be 'non-lossy' (TGA, PNG, TIFF) to lossy (BCn/DXTn)...
I will partially disagree on this:
the quality loss of DXT is a typically bit greater than the usual quality loss of JPEG (at higher quality settings, eg, 80% - 90%), so the added quality loss isn't really likely to be "actually noticeable" (vs going straight from PNG or similar).
the main reason to prefer PNG for distribution would mostly be that it natively supports an alpha-channel, rather than needing to have it added on either via extensions/hacks (the route I went), or as a separate alpha-image.
a downside I think of using RGB based formats for distribution is that the conversion speed is lower and using a fast conversion strategy generally tends to result in lower-quality compressed textures (more so with BC7, which can look "pretty good" with offline conversion, but where quick-and-dirty conversion tends to produce results "not significantly better than DXT").
this is mostly because a lot of BC7's more advanced features aren't really usable by a real-time encoder via any algos I am currently aware of, however, with a quick/dirty encoder, it is still possible to benefit from an increased color depth over DXTn.
this issue is partly why some amount of effort in my case is (still) going into specialized image formats and video-codecs, with the goal of basically being to do a little bit more work on the encoder side to produce higher-quality final output, while also being able to offer high-speed decompression (direct to DXTn / BCn).
though, at a downside that, at-least for video, the current size/quality falls a bit short of "real" video codecs (ex: MPEG-4, ...), albeit it is still fairly effective for animated textures.
decided to leave out a lot of the specifics, but it basically recently this means trying to design/implement what is looking like a "scary beast" of a codec (*) in the vague hope that it will be able to pull off around 0.05 bpp and still have 300 Mpix/sec decompression speeds, vs my existing codec which pulls off an "amazing" (0.25-0.5 bpp and ~ 300-400 Mpix/sec, though with rather lackluster image quality at said 0.25 bpp).
*: the goal still being to be able to quickly decode to DXTn / BCn. (previously, it was termed as being a VQ codec, but I don't really know if it counts, as it is more of a "hybrid").