I've been working with Clojure and most code is written using pure functional style. As a concrete example, Pedestal HTTP server has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code.

This has been a common scenario for the vast majority of Clojure programs I've worked on in the past decade. Core of the application does data transformations using native Clojure data structures. This is where all your interesting business logic lives. The interop lives at the edges and typically used for stuff like database drivers, HTTP servers, file access, and so on.

And I completely agree regarding immutability being the sane default.

I find that there are two major problems with OO. First is that it takes a lot of effort to learn how an API works because you have to pass object graphs around, and each object is a unique snowflake in terms of methods and behaviors it has. So, you often have to learn how dozens or even hundreds of objects are intended to be used.

Second, is that each object is effectively a state machine, and your application is structured as a graph of interdependent stateful objects. This makes it effectively impossible to reason about any non trivial application because all these relationships are too big to keep in your head. The only thing you can do is fire up a debugger get the application in a particular state and inspect it. Unfortunately, this is just heuristic since it's hard to guarantee that you've covered all the paths leading to a particular state.

Meanwhile with FP library APIs become data focused. You call a function, pass it some data, get some data back, and that's all you need to know. Data is both transparent and inert in nature. You don't have any behaviors associated with it, and you don't have to know what methods to call. The scope of information you need to keep in your head is drastically lower because you're able to do local reasoning.