In our experience most Topics should have a key. 

You should have a key whenever the act of writing data on a Topic logically represents updating the value of some data-object or a change in the state of the the system.  Specifically if you think that writing to a Topic "replaces" or "updates" a previously-written value.

If a Topic has a key, DDS can use that information to determine which data-object is being affected by your write operation. This allows DDS to implement QoS policies that properly manage the information maintaned by the system:

For example:

• The HISTORY QoS allows the DDS middleware to remember only the last N (history depth) updates to each data-object
• The DEADLINE QoS allows the DDS middleware to monitor that each data-objects is being updated at the specified rate
• The (Exclusive) OWNERSHIP QoS allows the DDS middleware to arbitrate between DataWriters so that  there is only one "active" DataWriter allowed to update the data-object
• The TIME_BASED_FILTER QoS allows the DDS middleware to filter rapid updates made to a data-object so that the DataReader receives at most one update per data-object per specified maximum period.

Generally speaking the definition of a key allows an application to fully leverage the capabilities of the DDS History Cache. This simplifies the application logic and can also result in significant overall performance benefits as it avoids duplicating that logic in application code.

You should not define key fields in a Topic if that Topic represents raw messages which have message-to-message identity. Meaning that there is no concept of a "write" operation updating the state of a data-object or replacing the old value with a new one. rather new messages are always "appended" to the existing set of messages. An example for this are messages representing transactions or logging events.