You would still have an issue where there is simply no functionality to killswitch all those novel APIs of arguable safety, and tell the browser to shut down any script not explicitly listed as allowed on the site.
Isn't that what CSP headers are for?
I saw websites with a screen long CSP header to work around standard's inconsistencies like frame-src/child-src, and form redirects. I think it's only a matter of time when somebody will find a chink in that weak armour.
The lack of sane by-default policy makes you vulnerable the moment attacker finds a way to redirect a browser to a non-CSP protected page on your domain. Mitigations exist, but... many buts.
Reflection attacks, when attacker injects your own hashed scripts, and data exfiltrating css on pages where they shouldn't be are still possible in various scenarios unless you inline all scripts, and set CSP per every URL.
Other data exfiltration sources, and injection sinks keep being found few times a year.
CSP is a paint over rust.
What do you imagine your more restricted JavaScript being permitted to do, where it is safe to run on a banking website?
The Web is broken, and CORS/CSP headers will only be able to fix only some individual cases, of a bigger, currently unfixable design problem.
The tons of random JS APIs brought into the browser without a any real critical review are making the initial design of scripts on the web being inherently secure, to them not being so.
The state of things needs to be brought back to the point where arbitrary JS simply cannot mess up your browser by design, and when you can load resources from everywhere safely regardless of tricky settings of now 10+ CSP related headers.
Or alternatively, there needs to be a solution to completely shut down those APIs, any "advanced" functionality to load 3rd party resources, reinforced by cryptohashes, and signature checks to verify loaded resources.