Writing tables/stored procs is not hard, many tools exist to make this pretty trivial (even including the foreign key relationships not feasible in the MUCK style tables).
What is hard is dealing with change to these structures.
Whilst in your development phase it is likely you will realise some aspect of the model was incorrect and requires simple (it's floats not integers) or complex (we need an additional layer between these two tables) alteration. If you have just the one development database this can be painful with multiple developers but is not the end of the world.
Change whilst in production can however be very complex and hard to deal with (sometimes requiring updating all the applications at once). CRUD stored procedures avoid almost all these issues for the simple changes but don't help at all for the complex ones (in fact they might even hinder it) but fundamentally the structure has changed in some significant way and it is likely that if you were using a MUCK that you would miss this in some way and start putting invalid data in to your DB.
Using Linq to Sql doesn't help a great deal here, since it just lets you write code that looks similar to sql[1] (stored procedures actually get in the way IMO) but it will let you know at compile time that your db code is no longer valid for some types of significant changed in the database schema (especially with regards to FK relationships). It is not much use for 'semantic' changes like altering the primary key to cover greater/fewer columns.
Whilst initially developing you can make the overhead of database changes much less by giving every developer their own database, preferably local. This is highly dependent on the associated costs involved of course.
MUCK tables can have their uses, especially when you want to be able to create/delete new 'columns' on the fly with next to no cost and maintain their lifetime values as well (schema updates play merry hell with many lifetime techniques) but such uses are relatively rare.
You can make Mucks slightly more pleasant in some respects (though worse in others) by having one table per type, you then get type validity on insert/lookup (you can add constraints that check that the 'category' being inserted is of the correct type if desired). Some of this can be hidden behind stored procedures.
[1] I like this don't get me wrong, it just doesn't help your specific issue much