The key thing to note is that in the definition of Free in scalaz we have

abstract class Free[S[_], A] { //..

This means S is the existential parameter and the compiler automatically puts a bound <: Any >: Nothing. An existential type means that the exact type is not known - it can be anything and code that depends on existentials also cannot assume any restriction there. Have a look here (http://www.artima.com/pins1ed/combining-scala-and-java.html#29.3).

Hi Debasish, I am excited about the book (and am recommending it to others) but I just reached Chapter 8 myself and I noticed the implementation in Section 8.4 (specifically the chaining with Next) is kind of messed up (no offense!). Notice how the `next` members feel like they are only there to conform to the template? (and why doesn't Opened need to take a Next as input when all the others do?) They aren't needed after all.

So first, the S[_] in Free[S[_], A] is not an existential type, but a higher-kinded type, another case of Scala using _ to mean too many different things in different contexts:
e.g.:

#1 an Event[A] represents a command that will return an A
#2 Opened will return an AccountNo, so it extends Event[AccountNo]
#3 Credited will return Unit, so it extends Event[Unit]
#4 calling open(...) produces an AccountNo, which we bind to n
#5 calling credit(...) produces unit, which we discard by binding to _

We can utilize the "free functor" instead of defining our own Functor (and introducing `next` just to give us something to map over) by using Free.liftFC instead of Free.liftF (even in scalaz 7.1) and then we can use Free.runFC to interpret the program according to a NaturalTransformation from Command to State.