The VBA Collection has 5 members, all of which are methods: Add , Count , Item , _NewEnum and Remove .
Of the 5 members, the Count method looks like it / should be a getter, not a method.
Is this a legacy of OOP / MS design from the early days of VB6? Did collection designers expect a time when Count might need to be a method, and designate Count as a method, so that some future behavioral changes would not break the / COM interface?
EDIT As Jim Hewitt points out in the comments, online documentation suggests that Count is a property, but Object Browser and MIDL suggest otherwise.
Here is the documentation for the VB6 Collection.Count Property
Returns a long (long integer) containing the number of objects in the collection. Only for reading.
But VB6 Object Explorer shows this: 
And in Excel 2016, Count sure it looks lonely and wants it to be a getter ...
EDIT 22 / Sep / 16:
I turned to Hardcore Visual Basic 5 by Bruce McKinney ...
This doesn't quite explain why Collection.Count is a method, but it somehow answers the question why I don't know why Collection.Count is a method:
Knowing the Unknowable:
everything you think about implementing the collection may be wrong for this version and probably will be wrong for the next version.
Implementation Information:
The Collection class provided by Visual Basic version 4 was a good version 1. The Collection class provided by Visual Basic version 5 is not a good version 2. Users suggested a lot of complaints and suggestions. None of them have been implemented.
In collections:
What is a collection? You know its user interface, but you really don't know what internal data structure makes it work. This is usually not a problem. Who cares about how it works while it works? But, on the other hand, internal implementation inevitably affects the efficiency of operations. If some operations are less effective than others, it might be nice to avoid slow ones.
On Collection.Item :
Visual Basic could do the work of [ Collection.Item ] [as a property]. (He was requested.)