This isn't an optimization at runtime. Mendix simply checks if the microflow has any other operations on that list during buildtime. In your case iterating the list is already enough.
Counting the list isn't a costly operation by itself. So in your case it doesn't really matter that it's not optimized to an SQL COUNT since you require the list content later on.
There are cases where you actually don't need all data in the list you're counting. Then it's better to first do retrieve+count and then retrieve the actual data you need separately.
Good question: The performance best practices also refer to the same.
The only thing I can imagine is that it is related to this statement:
"Microflows are executed as a single all-or-nothing transaction, which means that if any part of the microflow fails, the entire transaction is rolled back. Nanoflows, on the other hand, execute progressively with each activity, so if one activity fails, only that activity is undone"
So, the microflow "knows" the list will be updated/used before the retrieve action is actually executed.