It is easy to miss the point what the concept of a Specification is about, because there are so many bad articles floating around in the web.
Before the question was edited, you originally wrote:
And on the other hand, DDD says that this domain knowledge or logic must be inside the entity itself.
Em, no. Entities are not the only elements inside a domain model which can carry domain knowledge. Value objects can too, and the Specification objects as described in Evan's DDD book are value objects - specifically value objects which carry boolean logic. Entities together with related value objects form aggregates, these are the places where the domain knowledge lives.
I recommend to enhance your understanding by starting with this ~20 years old article written by Martin Fowler and Erik Evans about "Specification" mainly as an Analysis pattern, but also with some suggestions for possible implementations.
For simple cases, Specification objects can simply be seen as some kind of helper objects. They may appear when you see the need to refactor some boolean logic out of a domain entity, for example because you want to fight against an entity becoming a "god object", or because you see an opportunity to create an object where a piece logic can be unit tested on its own. Still the Specification does not have an identity on its own, it belongs to some domain entity, even if the code is not placed inside the same class. This is what the former article calls "Hardcoded Specification."
The logic might not be completely hardcoded, it could be also exchanged at run time by implementing Specification objects using the strategy pattern, or by introducing some parameters (which the article calls "Parametrized Specification").
For more complex cases, implementations like "Composite Specification" might be useful. This Wikipedia article shows a possible implementation. One confusing part here is that it just calls it "Specification pattern". This title is definitely too general, or the article itself way-too-specific, since it shows only the Composite approach. Another confusing part is that is presents a lot of code for the required framework, without making the purpose of the Composite Specification clear. The benefit of such a complex approach is to be able to modify certain business rules freely at run time. Hence it can be modified by input or configuration from some user, or by some external data source. This benefit comes for the price of having to build and use a mini-framework of "composite elements" around it.
"Composite Specification" is essentially a way to combine predicates (boolean functions) by standard conditionals AND, OR, NOT at run time. What you correctly have noted: this is indeed a functional task, and it can surely be implemented by functional means with less code and less overhead than with pure OO means.
Still creating specification objects makes perfectly sense in an OO and/or DDD context. Today, 20 years later, functional elements have become more and more popular in most major programming languages. Hence I think it should be easily possible to use a multi-paradigm approach and implement Specifications in a domain model using higher order functions or closures instead of ordinary value objects. Still this would be DDD and OO (with some functional "goodies"), I don't see any contradiction in this.
