Especially the last point is underestimated sometimes. A named scope can be tested explicitly in separation. Other tests, whose implementation relies on that named scope, then can stub out the scope with no remorse. This approach results in faster tests, because at least 2 database operations (write and read the object) can be avoided.
And easy to test implementations are the evidence for solid code.
However bad implemented named scopes also can lead to tight coupling between models.

The initial situation

The example is about bank accounts:

rails g model BankAccount serial:string && rake db:migrate

which can have many transactions:

classBankAccount<ActiveRecord::Basehas_many:transactionsend

That means each transaction belongs to a bank account and can be finalized at certain point of time:

it reveals a serious problem: the condition refers to a Transaction model attribute. That is tight coupling between both classes.
Instead the BankAccount should know nothing about the internal structure of Transaction.

Decoupled named scope

An alternative to the coupling named scope is moving the necessary condition into the Transaction model own named scope: