Inverse bit masks allow you more flexibility that merely using a netmask. The vast majority of applications simply invert a netmask into an inverse mask, like this:
! Deny tcp/25 traffic from all sources going to addresses
! in the seqence matching [172.16.0.4, 172.16.1.4, 172.16.2.4, etc...]
ip access-list 101 deny tcp any 172.16.0.4 0.0.0.0 eq 25
ip access-list 101 deny tcp any 172.16.1.4 0.0.0.0 eq 25
ip access-list 101 deny tcp any 172.16.2.4 0.0.0.0 eq 25
ip access-list 101 deny tcp any 172.16.3.4 0.0.0.0 eq 25
ip access-list 101 deny tcp any 172.16.4.4 0.0.0.0 eq 25
ip access-list 101 deny tcp any 172.16.5.4 0.0.0.0 eq 25
! keep repeating the pattern all the way to 172.16.255.4
Essentially, acl 101 blocks packets based on /32 netmasks. A more compact way of expressing the same is
! 255 in the third octet of the wildcard mask matches from 0-255
ip access-list 102 deny any 172.16.0.4 0.0.255.0 eq 25
ACL 102 is simply a more compact way of expressing the first ACL.
In the days when Cisco IOS switched all traffic based on CPU power alone and had no internal acl pattern optimizations built-in, ACL 101 would have been much slower than ACL 102 due to the number of entries in ACL 101. Now, Cisco IOS includes some significant optimisations in the pattern matching engine and higher-end platforms even use ASICs for filtering... so expressing an ACL as 102 does is more for convenience.
Keep in mind that your IOS configurations are only as good as your staff is at 3am in the morning when something is broken; so if you write ACLs as cleverly as possible, it's possible you will need a lot more time to debug things during an early-morning crisis.