GCC, the Google Closure Compiler, is still used by Google internally and they are shifting towards supporting the compiler for tools that emit "ClosureJS" (remember goog.define and goog.provide?). ClojureScript is one of several tools that target "ClosureJS" and there is not much to fear.
ClojureScript has always distributed GCC and GCL as date-versioned JARs since there is no formal release process of either component outside of Google. The GCL code "just works" for the most part and is frozen in time. GCL became unnecessary for two reasons.
1. GCL existed at a time when JavaScript had no notion of a module system whatsoever (not even CommonJS). It was very tedious to import third-party code. So GCL was designed as a kitchensink that'd work across browsers.
2. Many parts of the GCL kitchensink became unnecessary as the JavaScript standard library gained equivalent functionality and browsers standardized.
For instance, goog.net.BrowserChannel predates WebSockets and has lots of hacks so it works reliably on various versions of Internet Explorer. There has realistically been no need to use goog.net.BrowserChannel over WebSocket for almost a decade now.Another example: goog.crypt methods (base64, encodeStringToByteArray, etc.) are now provided by the JavaScript standard library
Yet another example: all of the functionality in the goog.async package (besides Debouncer) is provided by the JavaScript standard library through Promise.
Then there's other things that existed purely for browser compatibility, like goog.net.XhrIo (an XHR wrapper that isn't needed unless you care about IE5 quirks). Almost everybody, even in ClojureScript, uses fetch nowadays.
There's more examples, but look around for yourself and you will see that almost everything in the library can be served by modern JavaScript and a few NPM packages. https://google.github.io/closure-library/api/