I took your question as why not design the language to prevent the need for a convention in the first place? In other words, why doesn't Scala just force the use of parentheses all the time, instead of allowing programmers to omit them sometimes?
The answer is found in referential transparency. Essentially, if a function has no side effects, a function call can be replaced with its result, without changing the behavior of the program.
That means a function without parameters or side effects is semantically equivalent to a
val holding the return value of that function. Because of this property, as a class evolves, the programmer might switch back and forth between using a
val or using a function, as convenience or efficiency dictates.
Since you can omit the parentheses, that means code calling something like
queue.size doesn't need to know nor care if
size is a function or a
val. The implementer of the
Queue class is therefore free to change between the two without having to change any of the calling code (although I believe it will need recompiling). It stabilizes the public interface of the class. For example, you might start out a
queue.size by calling
size on an underlying
List, which is potentially
O(n), then change
size to a
val for reasons of efficiency.
The convention suggests the parentheses when there are side effects to make it clear that this class member is definitely a function call, and therefore potentially not referentially transparent. It's important for calling code to know if side effects are produced, so they can avoid calling it repeatedly. If you don't care whether it's a function or not, you may as well treat it as if it's not.