To refer to the initial discussion theme, Rysc summarized the Quartus 5.1 Handbook statements regarding safe FSM correctly. It clarifies, that OTHERS doesn't implement safe behaviour respectively, that Quartus didn't have a means to implement safe FSM behaviour. By using a binary state coding without unused states, a similar behaviour could be achieved anyway, if necessary for some reason.
The most common reasons for geting stuck in illegal states are violations of timing requirements, either with asynchronous inputs to a FSM or the clock itself, e. g. if the clock is supplied from an unsafe source, that can show glitches in some situations.
While the first problem can be easily avoided, the latter to my opinion contains a residual risk and may be a reason to use safe FSM. Although I basically agree with kaz, that safe behaviour must be achieved for the design as a whole, not only for an individual FSM, I think, that safe FSM in fact can help to make machines recover automatically from accidental states.