This is technically an accurate statement, the JavaScript ecosystem is massive and has excellent equivalents to just about every piece of useful Clojure FP construct out there.
But from a practical standpoint, when you start stitching these FP pieces together, you'll notice that the FP model in JS suffers immensely from the mutable-by-default design in its core data structures.
This means FP libraries have to accept and output these mutable-by-default data structures to gain any non-trivial adoption, which in turn often means they can't afford to use persistent data structures internally either, because recursively translating to and from the default mutable data structures, even just on the edges of the system, will often prove to be prohibitively expensive for most libraries. The entire JS ecosystem thus overwhelmingly assumes the use of mutable data structures, and in a program that tries to do FP in JS, any performance wins resulting from the use of structural sharing in persistent data structures (instead of naively cloning the default mutable data structures) get mostly nullified, if not outright negated by the need for recursive translation every time it needs to interact with third-party libraries or core browser APIs.
Even in systems that uses Redux (which as an architecture is about as functional as you can get, and outright forbids direct state mutation) overwhelmingly end up using built-in mutable data structures to represent state. Its Recipe page on "Using Immutable.JS with Redux" (https://redux.js.org/docs/recipes/UsingImmutableJS.html) is littered with a long list of caveats precisely because there exists far too many not-immediately-obvious performance footguns available for one to shoot themselves with when taking up the task of carefully micro-optimizing all the expensive toJS and fromJS calls they'd have to make to build anything non-trivial. This is of course not to throw ImmutableJS under the bus, because it provides an excellent set of persistent data structures by any measure. It does have an uphill battle to fight to justify its adoption though, because it exists in an ecosystem that compels users to reject it for no fault of its own.
I haven't even gotten started on the developer ergonomics of using non-native data-structures, which since ES6 has taken a (relative) nosedive, because of all the syntactic sugar that was introduced for the built-in data structures.
Contrast this with the ClojureScript ecosystem, in which the use of efficient persistent data structures is rarely ever a question, because that's the default, and every third party library and application written in CLJS can just take the associated performance benefits for granted.
P.S. Apologies for the rant. I've been switching back and forth between CLJS projects and JS projects for the past year, and this has always been my biggest pet peeve with the state of functional JS. I'm actually quite happy with just about every other aspect of functional JS, to be honest, but I fear JS may never reach its full potential as a functional language because of this core defect.