It is.
In my post I was only trying to tell that Thaddy's criticism for FreeAndNil went too far (imho).
In this particular case you are probably perfectly fine with using Free only. That's because you do it in the FormClose event handler, which I believe is the main form of your application. So after this handler will be executed and the destructor called on the instance referenced by the SnakeBody variable / property, you will probably never try to reference the SnakeBody variable / property again, because application will be terminated. So it doesn't really matter if the property still stores the reference of already destroyed instance.
However, if you would add FormDestroy handler (which is executed later in the TForm class lifetime), any attempt of referencing the SnakeBody there would give you access violations, obviously. You could try to prevent from that by checking if SnakeBody is nil (to mark that this variable / property is "invalid"). But you did not set the SnakeBody to nil after freeing it, either by simple assignment of nil to your SnakeBody, or calling FreeAndNil (which does exactly as the name suggest, fist Free, then assing nil - that's why it takes the parameter as var, so it can modify it).
My conclusion - as long as you will not try to "reuse" that variable that stored the instance that was destroyed, you are perfectly fine. But if you would need to "reuse" it (e.g. check if it is still valid, make decision if you need create new one, etc) - assign nil to the variable that stored the reference to the destroyed / freed instance, either by assigning nil after calling Free, or by calling FreeAndNil.