What's specifically functional about this advantage. Can't you encode the buisness logic into types in non-functional languages as well?

The word “type“ has a fairly different meaning in functional programming compared to object oriented programming. At a very shallow level, they have some similarities. But the way they are used is vastly different between the two paradigms.

The type systems that are common in functional languages are usually more flexible and useful than what you find in most other common languages (in particular, usually more useful than the type systems of common object oriented languages).

You can encode it, but it is not enforced. For instance, I can refer to every instance/argument when I use a Person object as `person` or whatever name of the class is, but when you have many developers working on a large system, these things tend to slowly spiral unless you establish strict guidelines early on and enforce through code reviews.

Or you can use types where it's enforced by the compiler.

On practice, no you can't. At least today.

But it may be a very interesting question for a researcher.

Something about putting business logic in a type system irks me more than someone building another compiler or database in Haskell.

Business logic relies so much on run-time values that (IMO) using data and predicates is a better fit.