I do use the `class` keyword in my js, but I'm also on a team of C++/Ruby programmers who are forced to write js, so the more I can do to make it more familiar, the better. As you said, it's just a tool. Some people like nails and some people like screws; there are objective advantages to each, but either one will hold a house together.
Immutability and thinking about if a class should really be stateful are the major wins.
I was recently looking over some code that essentially just did transformations, but all the inputs and outputs were member variables, so it took some effort to track what creates what and what depends on what. The members also had empty defaults, so if you mix up the order you call the functions in, the code still appears to work. It wasn't "wrong;" it was hard to follow and error-prone.
It's fine to want to go functionally heavy, but if you're not using classes - which are the foundation of 'types' - then why bother with 'type'script? (Unless you mean to say 'interface'? Which is obviously not 'class' but implies the same usage of OO-founded keywords)
The shape of data is more foundational than classes. An object without a class is a perfectly good way to organize data too, based on its shape.
At the end of the day, features of languages are just tools, and sometimes they fit the problem you're trying to solve. I think it's also important to decide what tools to use in the context of what experience you and your team already have.
Also, it's hard to have small .js files when you use classes, and I love small files. I think Go made a great design decision to allow functions on structs to be implemented in separate files.