I'll answer your four questions in a different way that I think makes more sense, which will hopefully also answer each one.
- Adobe RGB isn't "better" than sRGB. More specifically, it is better in some respects, but not others.
- Its coverage of the human-visible chromaticity diagram is slightly better than sRGB. But many programs don't understand colorspace, even if the OS does, and assume sRGB. In which case, image color and contrast will seem very noticeably "off". In that regard, sRGB is "better", as it's a universal standard and often assumed.
- Colorspace metadata can and sometimes does get lost when converting between formats and/or cloud services. Without that metadata, most programs and browsers universally assume sRGB.
- At 8 bits per color (aka "8bpc" or "24-bit"), subtle gradients are more likely to appear banded, with Adobe RGB as opposed to sRGB. Which is seemingly a paradox until you think about it. sRGB is covers less of the chromaticity diagram, so the numerical difference between perceptibly different colors that can be displayed, is larger. (With more possible integer values in between.) Axiomatically meaning, you can display finer gradients [but narrow total range] with sRGB, than Adobe RGB. But at 16bpc, that's not the case. (It's still technically true even at 16 or 32 bpc, just not noticeable to human perception, and the advantage of a wider coverage of the chromaticity chart is usually deemed worth the tradeoff.)
But if you switch to >= 16bpc to work more accurately with Adobe RGB, you might as well go with ProPhoto RGB, which is even wider. It has even more coverage of the chromaticity diagram. (It can even encode colors humans can't see, which is arguably a drawback, since that's "wasted" values that could have instead gone into encoding better cover the visible colorspace. That whole thing is a tough nut to crack, with everything involving tradeoffs, at least without using 32bpc floating-point representation and all RGB values being absolute, not mapped to a colorspace.)
But so far, ProPhoto RGB is unsuitable for things like website images. (Even if most modern browsers should and seem to be technically and perceptibly OK with it.) For now, ProPhoto and arguably even Adobe RGB should be thought of as more appropriate for intermediate processing steps.
Once an image is converted to it's final compressed form (e.g. jpg for web), a general rule of thumb is that it should be 8bpc sRGB. That may not hold true indefinitely, but still a good tip for now. Our eyes can't really tell the difference, for the end result. It's the intermediate processing, where you may need the extra fidelity. Once you stack a half-dozen semi-transparent layers on top of each other, each with multiple transforms, the mathematical precision loss at 8bpc can start to obviously show in the final output, when compared to the same process at 16bpc or 32bit floating-point.
The reason Gimp is prompting you about Adobe RGB, is because that's the working colorspace it's set up for. (Presumably.) You can change that.
So basically we wind up with these subjective and arguable recommendations:
- If you're doing very light transformations and/or have an underpowered computer, stick with 8bpc sRGB. It's simpler, it's more portable and universal, and less likely to cause problems.
- If you're doing heavier transormations and/or have horsepower to spare, go with 16bpc ProPhoto RGB but only as an intermediate format. (Which personally, I also use to store my "master" edit versions in.)
- For final presentation on a website or computer monitor, it's usually best to export to 8bpc sRGB:
- JPG for continuous tones and/or real-world photography
- PNG for synthetic and/or text-heavy images, especially those with fewer, more solid colors. (E.g. brand logos or non-dank text memes. Or anything that needs a transparent background, which JPG doesn't do.)
