To be honest, although I fully agree with the assessment that AtlasKit should either upgrade or remove Styled Components, your assertion that this will fix resource conflicts between apps in Server is incorrect. I’ve encountered the same issue with other packages in the past, incl. conflicts with Atlassian Jira native resources (not even other vendors).
The only way to work around this is to A) implement the use of iframes yourself in Server, which we do for all UI integrations where possible, and B) try to prevent use of global namespace by bundling your apps.
Unfortunately, as we both discovered, Styled Components (and also React) natively bind to the global namespace even if you use a bundler. In your case, you could have used an iframe in your gadget. In our case, we are limited by Atlassian because we need to detect if the user is on the Version, Release or Components page, and there are no page specifics contexts or entry points available in these pages. So our resources are loaded on every jira page (alt.general) only to detect whether it should do something.
One of the things we did do as a result of our both apps colliding is that we are now loading React & Styled Components asynchronously, and only if the user is on the Version, Release or Components page. That should limit the amount of collision points, although we still rely on the arrive package, which has caused a collision as well in the past.
Anyway, long story short: yes, Atlassian should do something about AtlasKit (see also Community request: can we have a no-bullshit update on the future AtlasKit? and Happy anniversary, great topic 🎉 RIP AtlasKit 🪦), but no, this will not solve the dependency collision on Server.