Well, this one often falls into the same religious-war category as allowing NULLs in columns; many people don't like to change their ways.  This thread should get rather heated.  Let's see if I can do this without stepping on a lot of toes...

That being said, I'll side-step putting 'usp' in front of procedures and address object prefixes in general.  In general, IMHO, they are rigid and unnecessary.  This affects tables, views, and table-valued functions more than procedures, but once you eliminate prefixes from many of your objects, you should get rid of prefixes for the rest of them.

The problem with table, view, and function prefixes is that tuning strategies and evolving application specs can force an object change.  For example, if I have a table called dbo.tblCustomer, and later turn it into a partitioned view over several tables, then either I leave the 'tbl' prefix on the new view - defeating the purpose of prefixes - or I rename the object to dbo.viwCustomer and go and update every piece of code that references it, a very expensive process to support using prefixes.

This thinking extends to column prefixes as well... ever had to change a column from an int to a decimal, etc.? 

In a more esoteric viewpoint, does the entity 'tblCustomer' hold rows of 'tblCustomers' or rows of 'Customers'.

In prefix-less systems with thousands of procedures, hundreds of tables, plus lots and lots of views and functions, I've found it quite easy to tell the difference in code between tables, procedures and functions.  Adding the prefix to every object just adds noise to the system.

-Eddie