On dimensions and compression
I recommend generating a compressed image (a “thumb” in Kirby parlance) from what the admins uploaded), or more likely 2-3 images (for use with srcset and sizes). Kirby lets you generate “thumbs” from a source image, specifying the width and/or height, cropping if needed, and the JPEG quality.
Define the source size you want, for instance if you’re generating a 800px image and a 1600px image, determine if it would work better with a 1600px source, a 2000px source or one even a bit bigger. Create a documentation for the client saying what dimensions, format and compression level each image type should have (for compression: probably 90-95% for a source JPEG, since you’re going to recompress it).
On the perfect size and compression level
Server-side JPEG encoders are often not great, and picking the same JPEG quality for all images in a given template is not ideal. Sure, you could get a perfectly fine image that is half of the weight with a better encoder or a manually picked, per-image quality. But your goal here is not to get to smallest possible solution, it’s to avoid damn the user uploaded a file that is a hundred times too big!!!. Automation requires compromises. 
Also for photos I wouldn’t care too much about serving the perfect image size and density for a device. I’m on a 13" retina laptop, and photos that are not too blown up look alright. So if there is a display width of 600px (that’s 1200 actual pixels on my screen) and the source JPEG is 600px wide and not too compressed it’s acceptable. If it’s a bit bigger, say 900px wide, it’s alright. No need to jump for a heavier 1200px image, unless it’s a 1200px image made specifically for high density screens, with a higher compression ratio to keep the weight down.
For photos, “good enough” is generally the best approach for being able to actually manage the performance (in practice, not just in theory) and keep your sanity. Making sure you have a double-resolution image is more important for things like logos, symbols, icons etc.
On connection speed
Connection speed is hard to detect, indeed you need JavaScript and it’s unreliable and any image referenced in the HTML code as <img src="url" alt="…"> will be loaded by the browser anyway, so you need to remove or obfuscate the image code, then write more code for the no-JavaScript scenarios. Not sure it’s worth it.
On loading many images
Of course a single image’s excessive size or weight can be a problem, but you should also look at the uses cases on your site where you’re using many images (e.g. more than ten). A long page? A photo gallery? Maybe some images should only be loaded on-demand (after a user action) or lazy-loaded (loading when the user scrolls, see lazysizes for that).
On managing client expectations
To have any success with front-end performance on a project, the client must be on board and you should be able to argue against some client expectations and demands if they’re performance killers. On the other hand, some business goals may mean that performance becomes a secondary objective.
If you go for fewer and smaller images, fewer and smaller videos and fewer and smaller JavaScript widgets, you’ll always get a performance win. But you might also get a less successful website.