The rationalle for the smaller LUN sizes, containing no more than 12-15 VM, back in the old days was driven by the locking mechanics used by VMFS. Modern day VMFS 5 datastores delivered from storage systems supporting hardware acceleration (VAAI), a new locking mechanism is used - Atomic Test and Set (ATS). ATS lifts that 12-15 VM limitation.
The amount of VMs per datastore is determined by capabilities of the underlying infrastructure. For example, if the storage LUN on which the datastore resides can service 4000 IOPS, the amount of VMs would be driven by the amount of IOPS each VM requires. It would be reasonable to put 100 VMs that require 40 IOPS on the datastore. It would also be reasonable to place 4 VMs that require 1000 IOPS on a datastore with the same 4000 IOPS capability.
Another thing to consider is, in an environment where backups are performed on a per-datastore basis, the amount of VMs per datastore would be dictated not only by the performance of the underlying infrastructure, but also by the amount of time allowed to restore that datastore in an event that would require a datastore restore. Array-based snapshots would also be an item to consider when determining what the best number of VMs per datastore should be.
In closing, there is no longer a hard/fast number dictating the amount of VMs that should reside on a single datastore.