I am hopeful that the discussion is useful to others, and that there are at least as many lurkers as there are typers 
You mean having the user's Data Entry Form enforce data validation rules?
Or something else perhaps?
I don't know if it is the right thing to do, but all our SProc that are "fed" from our Web Forms believe & Trust that the data they get is clean. Our Web Forms have very sophisticated validation abilities - our view is that the user prefers to be told that their data is invalid the moment that they type it, rather than "when they press SUBMIT". Immediately after completing a form field the thing they are supposed to be typing is fresh in their mind, and they have the appropriate piece of paper / email / telephone-conversation to-hand (and they have "parsed" that information). Telling them later that the data is goofy means they have to repeat all that data-acquisition & parsing all over again.
Our SProcs which get data from Other Data Sources, particularly other databases which our clients are Living and Dying by!!!, we do not trust - not even one-inch. In fact I am staggered that such clients make money, seemingly easily, with the rubbish systems they use ... We have a Data Vlidiation Errors module as part of our Data Integration module (which is responsible for sucking in data from "other systems"). If we see goofy data (i.e. anything for which we have a validation rule) we flag it in our Data Validation Errors table - their admin user gets an email alerting to "new additions to the errors table", and there is a report they can interrogate (which attempts to show them very specifically which Source Record and Which Column is at fault - in the hope that makes it easy for them to fix the problem in the source system). I'm talking about things like "Invalid email address" in a column that stores an email address. How hard can that be? Even something simple like "Don't allow 2x @" otherwise users will put a list of EMail addresses in there (which might be fine it that's what the field is intended to do, useless otherwise because the automatic mailing tool will not, by default, be expecting to get a list of TO address ...). Anyway, clients who are making good money, and think they have Clean Data, are usually running with 10's if not 100s of thousands of errors that our Data Integration modules has found ... and clearly 
the client is not motivated to fix ... it is depressing.
Hadn't thought about it before, but the chatter in the other recent thread about Static Code Analysis (http://forums.sqlteam.com/t/sql-lint-code-analysis-tools/2639) is also relevant to Client Data. The effort to convert fellow programmers to write tighter Defensive code should be able to be repeated, and sold as a chargeable sales product!!, to Clients who can improve the quality of their data using the same sort of static analysis and users trained to recognise the benefit & cost saving to the organisation.