I think Final is very useful in the following case:

like I did in Yaf, I got a Yaf class, there are some key resource need to be 
initialized. if these resource didn't intialized, then maybe segfault later.

so, I defined a constructor. and do such initialization. but user can extends my 
Yaf class, and they also might define there own constructor, and doesn't call the 
parent::construct... 

so I make the Yaf::construct final.... every is fine now.

@knight at kopernet dot org

IMHO that should be either a request to implement something like Reflection 
makeInheritable() . The final keyword has its uses and PHP isn't Java. If you're 
really in the mood, please consider writing your thoughts about what should be 
done as improvement at this place, and discussing it on the internals list. Such a 
request is rather useless without discussing all possible pro and contra.

But the implementation is sealed. The only way to override the construction is to use a factory method e.g. call your constructor and proceed with remaining initialization in the factory method.
My initialization in the extended class can be as critical as yours yet I cannot do anything to prevent someone creating an object of my new type with only your(e.g. base) constructor called.
On the other hand if someone creates an object and forgets to call your constructor and it's so obvious as you say it segfaults than the programmer gets feedback immediately so I don't get why you insist on preventing it.
But your point is very good. I've seen that hundred times: someone tries to extend a framework component without truly understanding its lifecycle. A sealed constructor is a good way to make sure it is used correctly. Better yet if the constructor is protected so that only the factory method can be used to create the object. That's however imposes the need to adopt the usage of factory method throughout your codebase.