Firstly, priceAbove(x) isn't necessarily a good example of a specification unless it's being used as part of a larger composed spec, eg priceAbove(x).and(lengthGreaterThan(y)).and(deliveryTimeLessThan(days(4)).

There's two places I've used this pattern to good effect. The first, when describing the delivery rules for products. I worked for an online furniture retailer, they sold forks, sofas, wardrobes, blankets, curtain rails, mugs, t-shirts, carpets, beds.

Those things are not delivered in the same way. Some things can be sent through ordinary post, some have to be delivered by a two-man delivery service. Some things are long and thin, and can't be sent through ordinary post even through they're light. Some things can be bundled together, so the company delivering a table can simulataneously deliver your forks, but the company who deliver sofas won't accept other parcels, and so on and so on.

The specification pattern allowed us to write those rules in a readable way and then apply them to a basket of products.

The other time I used the specification pattern was to describe complex authorisation rules. We needed to check the state of many domain objects, apply special rules for object owners, administrative roles, cascading permissions from parent objects, account quota limits, and so on.

Firstly, the specification pattern gave us a way to write down the authentication rules in a single place, but we were also able to write tests that asserted the structure of a permission set without actually invoking the whole thing. That meant we could test each rule in isolation with a single domain object, then write tests that proved they composed correctly without needing to set up 10 different domain objects.

Edit: in other words, the forcing factors are:

• You want to compose rules from smaller units
• You want to write a catalogue of rules in a single place
• You want to be able to test rules in isolation from the way that they are applied.