So that if someone tries to drop or modify the underlying table (or tables) in such a way that it would affect the definition of the view their ALTER TABLE command will fail with an appropriate message. If you have people changing table schema or dropping tables without ensuring that they fix any affected view at the same time, not having SCHEMABINDING on your views is a disaster; of course some of us think that people like that being able to modify the schema is a disaster anyway. But even with good people, mistakes can be made and if any of the mistakes are ones that SCHEMABINDING will prevent you obviously gain from it.

So in general it is a good idea to have SCHEMABINDING on all views, not just indexed ones. I think this is about the first time I've disagreed with Gail about anything. She's better at most SQL Server things than me, but here she's wrong: there are very good reasons for using SCHEMABINDING even when you don't want to index the view.

And you can't index a view that doesn't have SCHEMABINDING (i.e. what people used to call a MANIFEST VIEW has to have SCHEMABINDING) so any view you want to index has to have it.

There is something that some call a downside to SCHEMABINDING of course: it forces you to have a proper disciplined approach to upgrades - but again, some of us think of that as an upside, not a downside.

You should apply it to all your UDFs as well as to all your views.