I have almost always used no constraints. MY work is in civil engineering (mostly) where deadlines and constraints tend not to work. My job is to produce a workable, viable programme within the available time, and th esite team do their best to keep to it. Having no constraints/ deadlines means that as soon as th eprogramme is updated we get a revised planned completion date, and can react accordingly.

we also have client instructions, delays etc that need to be added into the programme and need to see these to assess any delay or benefit. by leaving the end date open, it is much easier to assess and evaluate current stage of work.

As a caveat, the contract completion date will usually be put into the programme as a Do Not Start Before, but this will only be used as a reference marker. Often (usually) this date will change anyway, and is therefore not a constraint or deadline as such.
My answer is based on site work (real world, if you like). If our project is overrunning I need to find a critical path and see i fwe can amend it - this is much easier with an unconstrained timeline, than one where a finish dare is forced and 90% of your programme shows as critical as it has been given negative float because of this.

This si not to say that the other options are invalid, but I think that the you need to consider the purpose and intention of the programme as well as the field it is being used in, which would be more relevent than an arbitary catch all answer.