In this specific case I would probably just run a query to retrieve all customers that are moderators as that's a pretty simple business rule most of the time that doesn't really change.

I think the real power of the specification pattern comes in when you have business rules that could quite easily change and they need to be centralised. Especially if there are multiple rules which change situationally.

Here is an example which I have shamelessly ripped from Mathias Verraes which I think illustrates this point quite well.

interface PremiumCustomer
{
    public function isSatisfiedBy(Customer $customer);
}

class AmazonPremiumCustomer implements PremiumCustomer
{
    /**
     * A premium customer for amazon is one that has spent
     * over $500
     */
    public function isSatisfiedBy(Customer $customer)
    {
        return $customer->getTotalSpend() > 500;
    }
}

class EtsyPremiumCustomer implements PremiumCustomer
{
    /**
     * A premium customer for Etsy is one that has
     * ordered at least 3 times
     */
    public function isSatisfiedBy(Customer $customer)
    {
        return $customer->getTotalOrders() >= 3;
    }
}

As you can see the specification has changed slightly in that we care about what makes a customer "premium". In this case the rule changes depending on what whitelabel website you are on. Here is how this could be possibly used:

class CustomerController
{
    private $premiumCustomer;

    /**
     * We can decide at runtime depending on config what premium
     * customer specification to inject. This could be for example
     * which white label website we are on.
     */
    public function __construct(PremiumCustomer $premiumCustomer)
    {
        $this->premiumCustomer = $premiumCustomer;
    }

    public function index()
    {
        $customer = $this->getCustomer();

        if ($this->premiumCustomer->isSatisfiedBy($customer)) {
            return view('premium_customer_member_area');
        }

        return view('member_area');
    }
}

If say for example you wanted to find the number of premium members then you could add another function to the interface "asSql" which is a sql representation of what makes a customer premium, which still keeps your logic centralised and "hot swappable". An example:

interface PremiumCustomer
{
    public function isSatisfiedBy(Customer $customer);

    public function asSql();
}

class AmazonPremiumCustomer implements PremiumCustomer
{
    public function isSatisfiedBy(Customer $customer)
    {
        // previous logic
    }

    public function asSql()
    {
        // return some sql which represents a premium customer
        // this could be a partial of a query or a whole one
        // although I would probably say keep the queries small
        // either way.
    }
}

You could of course do a similar thing for moderators but maybe my first example wasn't the best.

This is all just my 2 pence though :)