I can see that site-isolation is arguably too expensive on mobile and why you might want an opt-in mechanism there, somewhere down the line.
However, I don't think there are good arguments for not just enabling it on Desktop right now, without making developers jump through hoops. Until Chrome enables SharedArrayBuffers on mobile, I have no reason to care anyway.
Enabling that on desktop today would break every website that embeds cross-origin images, e.g. everybody using a separate CDN for images would be broken.
Chrome has been doing site isolation with multiple processes for a for a while, it "just works" and it doesn't break sites.
Also, you seem to be missing something: Chrome is going to implement the same set of headers, with the same set of restrictions when they are applied. This isn't an arbitrary firefox decision, every web browser is expected to follow suit. See the various mentions of "chrome" in https://web.dev/coop-coep/
That is not true.
https://www.chromium.org/Home/chromium-security/site-isolati...
https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zME...
So I guess you're right that if the sandbox "works" you don't care about cross-origin isolation, but it turns out that sandboxes don't work if you run multiple sandboxes in the same process.
The mitigation browsers have chosen is to isolate each origin in its own process, preventing other origins from communicating with it. To regain access to SharedArrayBuffer, you have to opt in to this extreme form of cross-origin isolation.
It would be nice to just make the whole web default to cross-origin isolation, but tons of websites rely on cross-origin communication features, and browsers can't just force them all to be compatible with isolation, so isolation has to be opt-in.