There will be a much bigger difference due to all the display variations out there than the actual compression, so I believe artists are out of luck here. No matter what they do it will look different on different screens.
There's a difference between the same image pixel data being shown on different displays, and altering the actual image pixel data as lossy compression does.
We do the same with audio in Construct. It is compressed, so why not graphics?
Graphics are compressed too. You can also opt-in to lossy JPEG compression.
Ideally ( if possible ) give people options, from what's currently in Construct to more severe compression.
The more options there are, the more development work we have to do, the more bugs come up in different combinations of settings, the more things have to be maintained over time, more documentation and support questions come up, etc. It's also not clear how lossy PNG compression would work, since PNG itself is a lossless format. Are there different pre-processing algorithms out there? How to they compare on the quality/size trade-off? Are they all appropriate in different circumstances or are alternatives necessary (which further increase the options)?
Also - as ever - we're a small team with limited resources, and already have years of work worth of features filed, so why should we work on this first and not other suggestions?
You can also already apply lossy compression if you want - just recompress the exported spritesheet images after export using your own tools. So you can basically do it already manually.