OOP does not impose any restriction on how you express solutions.

But it does. If you do OOP by the book, then there will be no "free functions" (that is, behaviors other than methods), and no "unadultered data" (that is, data that can be accessed or manipulated directly outside of the context of the owning object, nor data that isn't associated with any object at all).

Most OOP languages have "backdoors" to allow these things in some form or other, openly or covertly, but the same is true of "FP languages", practically all of which have "backdoors" to allow for mutable state and side effects.

In other words, the languages do not impose any restrictions, for entirely pragmatic reasons, but the paradigms do.

It just give you more tools: encapsulation, inheritance etc etc. FP while giving you some tools, it also says: “mutable state is bad. You should avoid it whenever possible”

Encapsulation isn't unique to OOP. Practically all typed languages, and most untyped ones, regardless of paradigm, provide a way of hiding implementation internals from the public API at some level. FP languages typically support closures, practically every language with a module system allows you to selectively export things from a module, and even good old C supports hiding implementation internals by not exporting them through the header (you can also declare procedures as "static", which makes them inaccessible from outside the compilation unit). Encapsulation is not an "object" concern, it's a "module" concern - it's just that in most OOP languages, objects also take on the role of modules, for most practical intents and purposes, and in languages that do have a separate "module" concept, that concept is usually rudimentary, redundant, or tightly coupled into the object system. At the same time, the OOP paradigm doesn't actually hinge on encapsulation - an object system that cannot enforce visibility will still work, and it will still allow you to fully implement OOP semantics (e.g., Python's OOP system doesn't really enforce encapsulation, it just strongly encourages it by hiding members whose names start with an underscore by default - they are still accessible, but because Python is untyped, and any programming discipline is essentially an honor system, it still works, and you can still write textbook OOP code in it).

Inheritance isn't unique to OOP either; the concept of "this thing is like that thing, except X, Y and Z" is readily available in procedural and functional programming too. A function can inherit from another function simply by selectively deferring to it; so can a procedure. Records, available in both procedural and functional programming, can trivially inherit from other records - just copy the original record and overwrite some fields. Some languages also support "extensible records" natively, that is, you can define record types in terms of other record types ("this record type has the same fields as that record type, but also these fields"), and again you can put functions or procedures into records as well, so this can also be used to implement polymorphic records-of-functions.

The key thing about OOP, IMO, is "open recursion", the ability to have methods call back into other methods of the owning object, and have those calls be resolved according to the object present at runtime. That is, if you have an object A with methods foo and bar, and foo calls this.bar, and then you have an object B that inherits from A and overrides bar, then calling B.foo will call B.bar, not A.bar, even though B.foo is the same as A.foo, and A knows nothing about the existence of B or B.bar.

(Side note: there is another definition of OOP, "Kay style OOP", which can be summarized as "whatever it is that Smalltalk does"; modern OOP is quite different from that, and one could argue that Erlang's actor model is maybe the closest to that in modern programming languages - but that's not what people generally mean when they talk about "OOP" these days).

Anyway, the thing with open recursion is that it's both a tool and a restriction - OOP gives you the ability to use open recursion, but it also forces you to deal with it at all times, because any object you work with may be a descendant of the type you demanded, and any methods you call on it may resolve to whatever the descendant wants. Open recursion gives you a lot of flexibility in what you provide, but it also takes away a lot of certainty in figuring out what you'll receive.

The same is true of the "restrictions" FP gives you. You gain the ability to mark expressions as "pure", and that allows you to completely ignore effects when reasoning about them or refactoring them, but of course it also means that you can't use anything that requires side effects (including mutable state) in a pure context.

But the thing is: everyone is fine by doing OOP + FP. Thats literally how all the modern programming looks like.

Bit of a fallacy here - first of all, they're not mutually exclusive, nor are they the only choices - procedural programming is still available, in fact most mainstream languages (whether they label themselves "object oriented" or "functional" or "multi-paradigm") trivially support it (though some of the more zealous ones require a bit of ceremony to pay lip service to their declared paradigm - e.g., in Haskell, if you want to write procedural imperative code, you have to use the IO type and monadic do notation; in Java, you have to declare pro-forma classes so your procedures can be "static methods"); and you can implement OOP semantics on top of an FP language, and you can write pure functional code in an OOP language. It may not be the most convenient approach, nor idiomatic, but the choice of programming paradigm is only loosely tied to the programming language you use, and you can certainly mix and match styles as you see fit.

Is restricting yourself and your team to pure FP that is generally a bad idea

Well, yes, obviously - a pure FP program cannot actually do anything except heat up the CPU, because pure code cannot be effectful, so there is no way a pure program can interact with the rest of the world (look up "Haskell is useless" on YT, where Simon Peyton-Jones, the "father of Haskell", explains this issue).

A common design here is to separate your program into a "functional core" and an "imperative shell" - that is, the "shell" handles inputs, outputs, and whatever other effects you need, in an imperative fashion (you can use OOP here, but it's rarely necessary - plain old procedural code works fine), and calls into a pure function that acts as an entry point to the pure functional program logic. Something like this (pseudocode):

pure function core :: Inputs -> State -> State
              core inputs state = 
                  return updated state

procedure main:
    state := initial_state
    forever:
        render state
        inputs := gather_inputs
        state := core state

A design like this is not a bad idea in general; it works really well for a lot of programs actually, especially those where the main complexity lies in the program logic, and the input/output layer can be relatively simple, such as server-side web applications, compilers, data wrangling tools, spam filters, DSP programs, etc. The huge advantage of this is that practically all the complexity lives in pure code, which means it's easy to refactor, easy to reason about, and easy to test; you still have a bit of imperative code that's harder to deal with, but you can keep it small and simple, and ideally, you won't need to touch it often.

It's probably somewhat less useful for things where the input/output part is intrinsically complex, such as video games or GUI frontends - the "imperative shell" is simply going to be very large, and so the benefits of keeping the logic in a separate pure functional core are relatively small. Input/output concerns are also more tightly coupled to program logic - for example, in a video game, adding an entity to the scene requires loading the relevant assets (3D model, textures, sound effects, etc.) from disk, adding them to the scene graph, and rendering them on screen; with the pure core / imperative shell approach, the imperative shell will now have to detect that the object has been added to the program state, and infer which assets to load in response, whereas if the logic is imperative and tightly coupled to the rendering, the logic itself can call into the rendering code to ask for the assets to be loaded, and store references to those assets in the logical object itself. (Note, btw., that I said "imperative" here - you don't actually have to use OOP for this, it can also be done procedurally, or using some sort of in-memory database approach, which you might call a "relational programming paradigm").