There's a mindset with SQL Server and like databases that have the capability of having stored procedures to have the database logic in the database itself for reusability and redundancy avoidance.
Yeah, that last bit it somewhat oxymoronic in your situation since you mentioned you have a lot of redundancy. However, it an ideal situation, you wouldn't need to validate in the stored procedure and in the web application. Pick a place and do it one time.
But, the idea behind this is that the same procedures can be used in ANY application that connects to the database. Web application, ETL, reporting, whatever. Single procedure to do one thing is the same across the board. If there's a bug, that bug appears in all those places, but only needs to be fixed in one place. That's the main idea.
So, is this normal? In some respects, yes. A lot of this has been solved multiple times over with ORMs (e.g. NHibernate), though those can often get in the way, too. It's a balancing act.
I normally create my own database wrappers and utility classes that handle a lot of these issues for me, though I still have to map the returned data to strongly typed variables. There's no real getting around that unless you create a smarter wrapper than I have that does that for you by inspecting either the meta data of the returned data to figure out the type, or if you're mapping to a known class, then doing reflection to get the property type and casting that way. It can be done with a little effort.