Why wouldn't I make every eligable Kotlin class a data class?

Question

I'm of course excluding any reasons that involve violating the rules for what can be a data class. So if you know you won't need to inherit from it for example (although it's my understanding that rule is going away in Kotlin 1.1).

1. Are there any disadvantages to making a class a data class?
2. Why don't all eligible classes provide the functionality of a data class as long as they remain eligible? This should all be detectable by the compiler without needing a special keyword. Of course the answer to this might be obvious depending on the answer to question 1.
3. Is there any reason for me not to mark all of my eligible classes as data classes?

Answer 1

data modifier makes Kotlin generate common methods like toString, hashCode, equals for the most commons (%80) scenarios based on the primary constructor.

This shows 3 reasons why only few classes should be data:

1. Most non-data classes have a mix of properties defined in the primary constructor and in the body of the class. Also the primary constructor often has parameter that are not fields (but help initialise more complex fields in the body). In other words, data has very restrictive requirements which are rarely met by regular classes.

2. In addition to point 1, making a class data may hurt its extensibility. Even if the layout of the class in question conforms to the rules of data classes, later someone may want to add another property in the body of the class. In that case he will have to manually override hashCode because it may be used somewhere.

3. Marking a class data sends a message to the one who reads the code that you intend to use this class as a data career. Marking other classes will be misleading.