Just from a performance aspect: An additional DNS resolve, additional TCP handshake, additional TLS, just to deliver a .js file that you could have easily served from the original website.
Not to mention the security aspect.
But there is still a problem with loading third party JS, even beyond the SaaS type that you expect to change regularly (where SRI+CORS becomes difficult-impossible to control), just loading Bootstrap has risks.
Although a good web developer hopefully knows how to add SRI, uses a validated third party library, will pick a fixed version and use a CDN with qualities as good as their hosting solution... they are rare to find and I doubt any data protection controller/officer responsible for GDPR should allow this risk.
The developer might: forget to add SRI; pick a CDN that allows tracking (read https://www.maxcdn.com/dpa/); pick a CDN registered or running servers outside of the EU.
So, the data protection office therefore has to check the terms of services of the CDNs, audit them regularly and then ensure there is appropriate staff training and QA to put in SRI and validate it it as needed.
Meanwhile, if the developer or data protection officer changes, there has to be enough documentation and process around to transition these practices to the next staff.. it all adds up.
Man power is often more expensive than CPU, so chucking the JavaScript in static hosting the company has control of is likely less for the DPO to worry about.
The only thing it got going for it, is the bandwidth savings for the original website.