I’ve never run into the situation where I was worried about a table being accidentally dropped (maybe I should have been?) as I usually let a good security model restrict that. But, accidents do happen.
So, if I ever need to make sure a table isn’t dropped I can use this technique by Roman Rehak. He creates a view using the SCHEMABINDING option, which binds the view to the table/schema so that the table (or other object) can’t be dropped without the view being dropped or modified. Taking a peek at BOL it looks like the same technique can also be used to make sure a table structure is not manipulated, as an ALTER statement will fail on a table that is dependent on a view, if that ALTER statement will affect the view definition.
In a dev environment with multiple developers possibly affecting a DB structure, I can see the ALTER check being more beneficial than the delete. But, if you get both for the same price…beautiful!