It's a bit of a tricky rule. Mendix uses an optimization in this specific scenario:
then the list is not actually retrieved, but only the aggregate is returned (you will also see this when you debug such a microflow: the list will not be available in the variables section, because it is not actually retrieved!). This increases performance: the database needs to send less information to the server (only the aggregate, as opposed to all items in the list) and the information from the database does not have to be mapped to objects.
If you use the list for something other than its aggregate, then the optimization will not take place and you will get the full list. Therefore, it may be better to do two retrieves: one retrieve + aggregate and one retrieve + whatever else you want to do with the list.
Now the tricky part: sometimes you want to use the list, but you also want to know it its number of items. The best way to model is is to retrieve the list, do a AggregateList with the count operation and then use the list. This will violate the rule. However, in Java – which is what Mendix uses under the hood – a list always has a size attribute, so getting the count of a list is a very cheap operation, much cheaper than a second database call.