- PNG and JPEG are both typically just going to end up as RGBA32 in memory, although it can vary per image format and implementation. In JPEG's case you're typically sacrificing quality for smaller storage size and potentially faster load time if you're truly IO-bound, but there are better ways to losslessly get the same gains.

- Although PNG data is arranged to be more zlib-friendly, it's basically just deflated image data. Of note, however, is that its decode times are typically measurably worse than raw deflated image data.

- If you're use PNG inside another container like .pk3, you're more or less double-deflating all of that data for no reason. In the case of JPEG, you're probably getting more marginal gains from one side of the compression despite the lossiness.

- If the target has a reasonably intelligent loading mechanism that allows asynchronous loading and decompression, once again you're working contrary to that by using a compressed image format like PNG or JPEG. Generally, that form of compression should always be handled at the archive level, and this allows the flexibility for the engine/implementation to choose from a variety of methods to maximize compression and minimize decode time.

- JPEG is generally lossy and looks terrible at reasonable rates after decoding in texture use cases, although PSNR will be highly subjective based on the image content.

- Less-lossy JPEG is generally not an effective means of image compression, its zigzaggy RLE falls over when it has to preserve frequency-domain (post-DCT) values with proper precision.

- Although Quake engines are likely to take the image data as-is and upload it as RGBA32, a lot of modern engines will (probably depending on some user preferences) want to take that data and DXT-compress (or PVRTC, ASTC, whatever the hardware target and implementation supports) it at runtime if it doesn't have a pre-cooked (probably encoded at higher quality) or previously-cached copy of the data. Since all of these compressed texture formats are lossy and block-based, this means you end up decoding lossy JPEG data and re-encoding it through a different, lossy process which only further deteriorates the image quality. If the engine has to do this every time, it will only be increasing your load times - otherwise the engine will be using its cached copy of the DXT/PVRTC/etc. data anyway, so you're only losing quality any gaining nothing else.