The rules are processed from top to bottom, each one appended after another. This quite simply means that if the entirety of your config file is:
block in all
pass in all
The computer sees it as:
block in all
pass in all
Which is to say that when a packet comes in, the first thing IPF applies is:
block in all
Should IPF deem it necessary to move on to the next rule, it would then apply the second rule:
pass in all

At this point, you might want to ask yourself "would IPF move on to the second rule?" If you're familiar with ipfwadm or ipfw, you probably won't ask yourself this. Shortly after, you will become bewildered at the weird way packets are always getting denied or passed when they shouldn't. Many packet filters stop comparing packets to rulesets the moment the first match is made; IPF is not one of them.

Unlike the other packet filters, IPF keeps a flag on whether or not it's going to pass the packet. Unless you interrupt the flow, IPF will go through the entire ruleset, making its decision on whether or not to pass or drop the packet based on the last matching rule. The scene: IP Filter's on duty. It's been been scheduled a slice of CPU time. It has a checkpoint clipboard that reads:
block in all
pass in all
A packet comes in the interface and it's time to go to work. It takes a look at the packet, it takes a look at the first rule:
block in all
"So far I think I will block this packet" says IPF. It takes a look at the second rule:
pass in all
"So far I think I will pass this packet" says IPF. It takes a look at a third rule. There is no third rule, so it goes with what its last motivation was, to pass the packet onward.
It's a good time to point out that even if the ruleset had been
block in all
block in all
block in all
block in all
pass in all
that the packet would still have gone through. There is no cumulative effect. The last matching rule always takes precedence.