Some of the more popular functional languages have advanced type systems, but not all functional languages are statically typed. Lisp, the granddaddy of all FP languages, is dynamically typed. So is Elixir.
Can we stop conflating FP with static typing?
Static type systems can greatly hinder FP. Or to be more specific, language semantics and runtime behavior (encoded by the type system) can influence how powerful your FP is - and by "powerful", I mean how much boiler plate you need and how much you can generalize things.
So yes, having certain characteristics of type systems do help with FP while not being core to FP. It can certainly make things more pleasant though.
I'm all for that, but first we probably need to actually define what "functional programming" means, which seems to be one of the great unresolveable debates of computer science. :P
To wit, I can think of no reasonable definition of functional programming that includes Lisp, Scheme, ML, and Haskell that does not also include every popular language aside from C. Even Java has first-class functions these days, sort of...
The definition I have in my head is something along the lines of "functions are the tool that the language prefers to address common software design concerns." So for example, Encapsulation is a big deal when designing software. Object-oriented languages will address this concern with their object system (via accessibility modifiers), while function-oriented languages tend to address this with functions, via lexical scoping and closures. OOP languages use their object system to achieve runtime-dynamic behavior through inheritance or composition or interfaces, while function-oriented languages will more often try to pass first-class functions as arguments. And so forth.
It's not a 100% thing. Common Lips will solve some of its problems with macros or its module system, and ML will solve some of its problems with types. But you do find the languages (or communities) prefer functions over their object systems, while e.g. Python or Ruby prefer the reverse.
Although, I do find myself wondering if Haskell should actually be considered a type-oriented language. Again, it's not just about the features of the type system, it's the fact that the type system is the main tool that it tries to use to solve every problem about designing software.
We see a lot of definitions of functional bandied about, often conflating functional with Haskell or with Scala. Those definitions seem to ignore the history of functional programming, including Lisp, as qsymmachus noted. So that's silly. And conversely, one sees a lot of definitions of OO that appear to mean "Java" or "C++". Again, nonsensical when one considers Self, or to a lesser degree Smalltalk.
I do like your conception wherein a language is function to the degree to which it prefers functions as its favourite tool for solving problems, and/or OO to the degree to which it prefers objects as its favourite tool.
Regarding encapsulation as your particular example, OO is clearly fairly obsessed with encapsulation, being almost the definition of an object: a bundle of encapsulated state with the externally-facing behaviour that that object affords. I think that many functional communities/practitioners see this as a much less urgent issue, often going so far as to make no active effort toward encapsulation at all (i.e. not everyone bothers with the lexical-scopes-and-closures solution). Thus we get ideas like "smart functions, dumb data", an idea which makes no sense in OO land.
I've never found a better explanation of the real ontological differences between these paradigms than this section at the end of chapter 3 of SICP: https://sarabander.github.io/sicp/html/3_002e5.xhtml#g_t3_00...
> We can model the world as a collection of separate, time-bound, interacting objects with state, or we can model the world as a single, timeless, stateless unity. Each view has powerful advantages, but neither view alone is completely satisfactory. A grand unification has yet to emerge.
I feel Static typing is like those little wheels fitted to bicycles so kids don't fall down when riding a bike. Yes, you can never fall down when using those wheels, but (a) your cornering ability will be slower and (b) you still can crash against something, fall into a pit, etc...
Lisp is a multi-paradigm language of which FP is one of them. You're referring to Standard ML or Haskell and that should explain why people conflate FP with static typing.