can you clarify the context/motivation for this?

Without two message instances can't easily be compared if they contain the same values. The user would need to compare each and every field (as well as recursive fields) manually. Also if the message later changes and a field is added the existing checks would be incorrect.

I found this article with a good overview: https://hynek.me/articles/hashes-and-equality/

Should we remove the __hash__ method based on that?

From: https://docs.python.org/3.5/reference/datamodel.html#object.__hash__

If a class defines mutable objects and implements an eq() method, it should not implement hash(), since the implementation of hashable collections requires that a key’s hash value is immutable (if the object’s hash value changes, it will be in the wrong hash bucket).

I think it's right to implement __eq__ but drop the __hash__ implementation.

drop the __hash__ implementation.

Done in 2756c3f.

FWICT ros1 time msg types are hashable: https://github.com/ros/genpy/blob/b244f2f50813ce0385c8673a899bce9e140a35d8/src/genpy/rostime.py#L127..L131 which might cause migration issues to ros2 for some code (unless times in ros2 are immutable? I don't think so). Not much to change, just an observation that came up from the hashable discussion which might be worth adding to the migration guide?