Site isolation disables all of it. With "Cross-Origin-Embedder-Policy: require-corp," you can't even embed a cross-site image unless the other image allows it with a "Cross-Origin-Resource-Policy: cross-origin"
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.
You're describing how this proposed cross-origin isolation scheme works. I understand that, I don't understand why it is necessary to make it work that way.
Chrome has been doing site isolation with multiple processes for a for a while, it "just works" and it doesn't break sites.
Site isolation and origin isolation are separate concerns. In the "origin isolation" model, you need to ensure different origins are in different processes, and that their data don't leak from one to the other. In site isolation, you only care about tabs not being able to communicate with each-other.
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/
Chrome’s site isolation doesn’t solve the “image from another origin” problem. Those still exist in the containing origin process’s memory. It solves the “frame from another origin” problem, which is the more acute issue but not the only one.
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.