However, this sort of situation is pretty rare in my experience though.
If you have other strong references to this tableview, such as other controllers, it would then be possible that the tableview could then exist longer than the MyViewController class. In such a case, it would be necessary to set the UITableViewDelegate and UITableViewDataSource to nil in the dealloc method of MyViewController because, as you mentioned, these properties are NOT weak references and will not automatically be set to nil.
Most of the time, I don't worry about setting these to nil honestly, but it is a defensive programming practice.
The reason is that once the dealloc method on your MyViewController is called, the tableview will also be destroyed along with the controller (that is, once again, as long as the only reference to it is your sole controller MyViewController class).
We have a small app with only a couple hundred users, and I'm seeing 3-4 crashes per day related to this. CoreAnimation is in the stack, so I suspect an animation is holding onto a strong reference to the table after its controller (delegate and dataSource) have been freed. I haven't managed to reproduce this, however. This may not be an issue if you're using UITableViewController and the delegate and dataSource are set to the UITableViewController. Apple clears them out in the dealloc method in this case.